Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#294 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
48/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
node.js, typescript
Domaine
cli, performance

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
TypeScript
Étoiles
364
Forks
32
Merge moyen
1 j 4 h
PR mergées (30 j)
37

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de modelstudioai/cli

Toutes les issues de modelstudioai/cli

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.