* perf(core): load the MCP client's Google auth providers on demand
mcp-client imported GoogleCredentialProvider and
ServiceAccountImpersonationProvider statically, so every process that
loads the MCP client, including each resident Managed Runtime worker,
also loaded google-auth-library whether or not any server uses Google
authentication. createTransport is already async; import each provider
only for a server configured with it.
Add transport tests for the service-account impersonation provider,
which had none in this file. On Linux x86_64 an idle worker loads
0.24 MiB less JavaScript and holds 0.9 MiB less private memory.
* fix(core): ask for a restart when a Google auth provider chunk is missing
Now that the MCP client imports its Google auth providers on demand, the
bundle puts them in separate chunks. A background update that replaces
dist under a long-lived process made the next connection fail with
"Cannot find module", wrapped as a connection error for the server.
Move the restart guidance that contentGenerator already gives for its lazy
provider chunks into utils/errors (getModuleNotFoundError,
wrapLazyModuleLoadError) and apply it to both provider imports. The
original error stays as the cause.
Add google-auth-library to the ACP static closure guard, so a static
import of either provider fails check-serve-fast-path-bundle again.
* test(core): isolate the lazy Google auth chunk tests in their own file
Co-authored-by: Qwen-Coder <[email protected]>
---------
Co-authored-by: Qwen-Coder <[email protected]>
* refactor(core,cli): rename Gemini residue in memory/spinner/leaf ids
PR 1 of #4063 item 6 (de-Google naming). Renames three independent families plus the leaf LLM types:
- Memory filename: GeminiMd* -> Memory* (project memory file, not an LLM client)
- UI spinners: GeminiRespondingSpinner/GeminiSpinner -> RespondingSpinner/Spinner
- Leaf types: GeminiCodeRequest/GeminiChatSendOptions/GeminiErrorEventValue/GeminiFinishedEventValue -> Llm*
- geminiRequest.ts -> llm-request.ts (and its collocated test)
No behavior change. Renamed symbols typecheck clean in core+cli; eslint clean on renamed files.
Refs #4063
* fix(cli): resolve rename build failure
* docs(serve): fix memory filename references
* test(cli): pin primary workspace QWEN.md init fallback
Assert that the primary daemon workspace service receives the
hard-coded 'QWEN.md' context filename when boot settings carry no
context.fileName. Previously only the secondary workspace's explicit
SECONDARY.md resolution was asserted, so swapping the fallback literal
at the createDaemonWorkspaceService call site survived the suite.
* refactor(core,cli): finish Gemini residue rename in memoryDiscovery
Complete the rename flagged in review: GeminiFileContent -> MemoryFileContent (module-local interface), includeDirectoriesToReadGemini -> includeDirectoriesToReadMemory (parameter only; all call sites are positional, zero cross-package impact), plus test-local variable names and the stale ORIGINAL_GEMINI_MD_FILENAME test title.
* docs(design): route loadHierarchicalGeminiMemory to Memory naming
Per exception #1 the Llm prefix is reserved for the generic LLM-client surface; the symbol is a memory-file loader (thin wrapper around core's loadServerHierarchicalMemory), so the PR-2 symbol map targets loadHierarchicalMemory instead of loadHierarchicalLlmMemory. Doc-only: the code symbol is not renamed by this PR.
* docs(cli): narrow extractContextFilename fallback description
The undefined fallback first inherits the primary workspace's configured context.fileName snapshot (contextFilenameForInit) at the secondary startup and dynamically added workspace call sites, before the hard-coded QWEN.md. Describe the actual chain instead of the hard-coded default only. Comment-only: the inheritance behavior predates this PR and is unchanged.
* refactor(cli): rename loadHierarchicalGeminiMemory to loadHierarchicalMemory
The design doc's symbol map routes the memory loader to
loadHierarchicalMemory (memory family, exception #1), but no phasing
bullet performed the rename and a prior round left the mixed signature.
Complete the rename across the definition (config.ts), the AppContainer
call site, and the AppContainer test mocks, and update the design doc's
exception #1, symbol map, and PR-1 phasing bullet so the map row is no
longer orphaned.
* fix(core): preserve Gemini rename compatibility
* docs(core): extend Gemini deprecation window
* refactor(core,cli): rename Gemini LLM identifiers
* fix(core): retain Gemini content generator aliases
* docs(core): document legacy content generator paths
* ci: trigger checks after retargeting to main
* test(cli): update renamed LLM expectations
---------
Co-authored-by: qwen-code-dev-bot <[email protected]>
`packages/cli/src/cli.ts` is the esbuild entry point and bootstraps only under a
main-module guard:
if (process.argv[1] !== undefined &&
import.meta.url === pathToFileURL(process.argv[1]).href) {
void runCliEntryPoint();
}
The bundle is built with `splitting: true`. If any module the entry loads lazily
(e.g. `gemini.tsx`, reached through `await import('./gemini.js')`) adds a static
`import ... from './cli.js'`, esbuild moves the entry module's body into a shared
chunk and leaves `dist/cli.js` as a re-export stub. Inside a chunk
`import.meta.url` is the chunk's own URL, so the guard never matches and the
bundled CLI exits 0 without running anything.
Nothing catches that today: tsc, eslint and every src-based unit test stay green,
because the breakage only exists in the bundle. The single CI step that executes
`dist/cli.js` is the no-AK integration smoke test, which reports it as
`daemon exited with 0 before listening` from three unrelated serve suites — a
symptom that points nowhere near the import that caused it.
Assert instead that the entry output still compiles the entry module. When the
entry is hoisted, `dist/cli.js` keeps no inputs of its own, so the metafile the
existing closure checks already read is a precise signal, and the diagnostic can
name both the cause and the fix.
Co-authored-by: verify <verify@local>
* perf(startup): load undici lazily behind package-local dynamic imports
* fix(web-search): preload undici before building runtime fetch options
Address review: web search builds fetch options outside the content
generator preload path, so 33 web-search tests (and any standalone
search invocation) hit the requireUndici fail-loud guard. Also redact
and rethrow proxy dispatcher install failures, guard early promise
rejections against unhandledRejection, and pin the guard message with
a test.
* test(cli): cover loadUndici interop and gitUtils proxy path
Address review suggestions: add parameterized tests for the CJS
unwrap normalization used by both core and cli loadUndici helpers,
and verify getLatestGitHubRelease instantiates ProxyAgent when a
proxy argument is passed.
* fixup! test(cli): fix loadUndici test type errors
Export UndiciModule type and loosen test helper typing so the cli
package builds under tsc --build.
* perf(telemetry): lazy-load the SDK and split OTLP exporter chains by protocol
* fix(telemetry): close lazy SDK init/shutdown races and make load failure non-fatal
Addresses PR #7276 review feedback: shutdown now awaits an in-flight init before tearing down (was racing past the sync flag and leaking a started SDK whose buffered spans/logs never flushed); the dynamic imports now sit inside init's try so a chunk-load failure degrades telemetry instead of aborting daemon runtime startup. Also breaks the sdk<->sdk-impl import cycle via a leaf otlp-urls module, hardens the sdk-node exporter stub for thenable/interop probes with a unit-tested separator-independent resolve, lists the HTTP exporter packages explicitly in the bundle guard, and adds lazy-init lifecycle tests.
* test(core): stabilize file history eviction test
* ci: clean package build artifacts before fast-path check
* ci: preserve web build outputs during fast-path check
