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

Đang mở
  • Có gì không ổn?
#294 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
node.js, typescript
Lĩnh vực
cli, performance

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
TypeScript
Star
364
Fork
32
Merge trung bình
1 ngày 4 giờ
Pull request đã merge (30 ngày)
37

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của modelstudioai/cli

Tất cả issue của modelstudioai/cli

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.