[bug]: bl lingers ~50 s after answering (Windows)

Aberta
  • Algo errado?
#294 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
48/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
node.js, typescript
Domínio
cli, performance

Direção de pesquisa

Start with packages/cli/src/main.ts and packages/core/src/client/transport.ts to trace what keeps the process alive after a successful run; compare with the SIGINT path in packages/runtime/src/create-cli.ts. The report also raises registry configuration in packages/runtime/src/utils/update-checker.ts, so clarify whether that is in scope. Done means the command exits promptly after its JSON is written, with tests covering the affected behavior.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

bug
CLI version

2.7.2

Skill version (optional)

No response

Node version

v26.13.0

OS

win32 x64, Windows 11 build 28120, invoked from PowerShell 7

Region

cn

Command to reproduce
bl usage token-plan --output json
Expected behavior

the process exits as soon as the command has answered; the JSON document is on stdout at that point.

Actual behavior

the document appears in about 0.8–1.2 s, then the process stays alive for about 50–56 s before exiting with code 0. Anything that spawns bl and waits for the exit pays that wait: a plugin or an agent tool that reads the quota ends up with a ~50 s child instead of a ~1 s one, and the only workaround outside the CLI is to kill it once the document is complete.

Full output

No error: exit code 0, the document is correct. Timings, with the process allowed to finish:

form output complete process exit
release binary (bl-2.7.2-windows-x64.exe) 784 ms 54.7 s
release binary, NO_UPDATE_NOTIFIER=1 786 ms 56.1 s
release binary, ~/.bailian/update-state.json set to "checked just now" 2009 ms 54.4 s
npm entry (node node_modules/bailian-cli/dist/bailian.mjs) 3961 ms 4.3 s
npm entry, NO_UPDATE_NOTIFIER=1 886 ms 886 ms
bl --version (no network call) — 691 ms
JSON error (optional)
Already tried
  • bl update and skill version aligned with CLI
  • bl auth status OK for this command
  • Different network / region — still reproduces
How often does this happen?

Always

How was bl invoked?

Terminal (manual)

Notes (optional)

Where the exit waits. packages/core/src/client/transport.ts sends the release binary's requests through globalThis.fetch, and the npm package's through undici's global dispatcher. Both keep the connection pooled. undici's keep-alive times out in about 4 s, which is what the npm form's 4.3 s shows; the release binary's pool holds the process instead.

It is not the version check: the binary takes ~54 s with a fresh and an aged ~/.bailian/update-state.json, and with NO_UPDATE_NOTIFIER=1 as well. That flag is what the npm form responds to (4.3 s → 0.9 s, i.e. it only skips the check's own FETCH_TIMEOUT_MS = 3000).

packages/cli/src/main.ts ends with void createCli(...).run();, and process.exit is reached only on errors (runtime/src/error-handler.ts), on SIGINT after flushTelemetry(500) (runtime/src/create-cli.ts:113) and on EPIPE (:118). A successful run therefore waits for every pooled socket before the event loop drains.

Possible fix. Exit after the run resolves, the way the SIGINT path already does:

const code = await createCli({ ...commands, ...commandAliases }, { /* … */ }).run();
process.stdout.write("", () => process.exit(code));

For the node path, getGlobalDispatcher().close() would have the same effect; the release binary's fetch has no close, so the explicit exit is the option there. Either way the document is already on the wire, so nothing is lost.

Separate ask: the version check should follow npm's registry configuration. packages/runtime/src/utils/update-checker.ts hardcodes NPM_REGISTRY = "https://registry.npmjs.org". On a machine whose npm is pointed at a mirror or a private proxy (registry=… in .npmrc, or the npm_config_registry environment variable npm exports), the check still calls npmjs directly: here it sits behind a proxy for the whole FETCH_TIMEOUT_MS on every run that is due, and it can never see the mirror's dist-tags, so a mirror-only environment gets a slow check and no update notice.

Suggestion: resolve the registry the way npm does — an explicit npm_config_registry (or NPM_CONFIG_REGISTRY) first, then the nearest .npmrc registry=, then https://registry.npmjs.org — and let the same environment variable win for the standalone binary, which has no npm around it. That also makes the check testable against a mirror instead of the public registry.

Linguagem predominante
TypeScript
Estrelas
368
Forks
34
Merge médio
1d 4h
PRs com merge (30d)
37

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de modelstudioai/cli

Todas as issues de modelstudioai/cli

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.