@dptech-corp/bohr-cli 2.7.0 → 2.7.2

package/CHANGELOG.md

@@ -22,6 +22,28 @@
 
 ## [Unreleased]
 
+## [2.7.2] - 2026-09-20
+
+### Breaking
+
+- **参数值错误统一分类**：支付来源、批量作业支付类型、结构检索参数值不合法时，`COMMAND_FAILED` 改为 `VALIDATION_FAILED`；调用方按新码修改参数。
+- **交付物空列表统一为数组**：`agents artifacts list` 无结果时由 `artifacts: null` 改为 `artifacts: []`（含 `--all-files`）；调用方按数组长度判空。
+
+### Fixed
+
+- **停止批量作业的确认等待遵守时限**：`batchjob kill --confirm-timeout` 也约束挂住的状态查询；到期报告已受理但未确认，提前取消则明确提示确认中断。
+
+## [2.7.1] - 2026-09-19
+
+### Changed
+
+- **中断后的退出码**：自行处理中断的命令（如 structure search 下载）被 Ctrl-C 后返回自身的退出码，不再是 130；未处理中断的命令不变。
+
+### Fixed
+
+- **只停启动器也能停下 CLI**：`timeout`、Agent 框架超时只给 `bohr` 进程发信号时，CLI 不再成为孤儿继续运行、占着输出，而是照常处理中断后退出。
+- **结构下载被挂断时不留临时文件**：关掉终端或收到 SIGHUP 时，`structure search --download` 同样清理临时文件并报下载已取消。
+
 ## [2.7.0] - 2026-09-18
 
 ### Breaking

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dptech-corp/bohr-cli",
-  "version": "2.7.0",
+  "version": "2.7.2",
   "description": "CLI tool for Bohrium scientific computing platform",
   "bin": {
     "bohr": "run.js"
@@ -32,11 +32,11 @@
     "CHANGELOG.md"
   ],
   "optionalDependencies": {
-    "@dptech-corp/bohr-cli-darwin-arm64": "2.7.0",
-    "@dptech-corp/bohr-cli-darwin-amd64": "2.7.0",
-    "@dptech-corp/bohr-cli-linux-amd64": "2.7.0",
-    "@dptech-corp/bohr-cli-linux-arm64": "2.7.0",
-    "@dptech-corp/bohr-cli-windows-amd64": "2.7.0",
-    "@dptech-corp/bohr-cli-windows-arm64": "2.7.0"
+    "@dptech-corp/bohr-cli-darwin-arm64": "2.7.2",
+    "@dptech-corp/bohr-cli-darwin-amd64": "2.7.2",
+    "@dptech-corp/bohr-cli-linux-amd64": "2.7.2",
+    "@dptech-corp/bohr-cli-linux-arm64": "2.7.2",
+    "@dptech-corp/bohr-cli-windows-amd64": "2.7.2",
+    "@dptech-corp/bohr-cli-windows-arm64": "2.7.2"
   }
 }

package/run.js

@@ -1,5 +1,5 @@
 #!/usr/bin/env node
-const { execFileSync } = require("child_process");
+const { spawn } = require("child_process");
 const path = require("path");
 const os = require("os");
 
@@ -66,18 +66,58 @@ try {
   );
 }
 
-try {
-  execFileSync(binaryPath, process.argv.slice(2), { stdio: "inherit" });
-} catch (e) {
-  // e.status is null when the child was killed by a signal; exiting 1 there
-  // would report an ordinary failure for a SIGINT. Exit codes are how the
-  // billing gate (10) and every other envelope code reach the caller, so this
-  // must pass through untouched when there is one.
-  if (typeof e.status === "number") {
-    process.exit(e.status);
-  }
-  if (e.signal) {
-    process.exit(128 + (os.constants.signals[e.signal] || 0));
+// Signals sent to this launcher must reach the binary. A caller that stops bohr
+// by pid — `timeout`, Python's Popen.terminate(), an agent framework's step
+// timeout — only ever signals this process. It used to run the binary with
+// execFileSync, which blocks the event loop, so node took the default action and
+// died on the spot while the binary kept running as an orphan, still holding the
+// caller's stdout. The caller then waited on a pipe nothing would close.
+//
+// A terminal Ctrl-C reaches both processes (same process group), so the binary
+// sees SIGINT twice. That is the usual trade-off of a forwarding launcher
+// (internal/toolproxy/exec.go makes the same one): a command without a SIGINT
+// handler is already gone when the copy arrives, and a command with one keeps
+// catching until it has written its envelope, so the copy is absorbed.
+//
+// Windows is left alone. Console Ctrl-C already reaches every process on the
+// console, and child.kill() there is TerminateProcess, which would cut off the
+// binary's own cancellation handling. Listening is still worth it: node then
+// waits for the binary instead of exiting first and handing the prompt back
+// while it is still writing.
+const FORWARDED_SIGNALS = ["SIGINT", "SIGTERM", "SIGHUP"];
+const forward = platform !== "win32";
+
+const child = spawn(binaryPath, process.argv.slice(2), { stdio: "inherit" });
+
+const listeners = new Map();
+for (const signal of FORWARDED_SIGNALS) {
+  const listener = () => {
+    if (forward) child.kill(signal);
+  };
+  listeners.set(signal, listener);
+  process.on(signal, listener);
+}
+
+child.on("error", () => {
+  // Only a spawn failure (missing binary, no exec bit) ends up here with no
+  // pid; execFileSync reported those as a bare exit 1 and so does this. A
+  // failed kill also emits "error", but the binary is still running then and
+  // "exit" will follow.
+  if (child.pid === undefined) process.exit(1);
+});
+
+child.on("exit", (code, signal) => {
+  // Exit codes are how the billing gate (10) and every other envelope code
+  // reach the caller, so they pass through untouched.
+  if (typeof code === "number") process.exit(code);
+  for (const [name, listener] of listeners) process.removeListener(name, listener);
+  if (signal) {
+    // Die of the same signal instead of exiting 128+n: a shell script only
+    // stops at a Ctrl-C when the process it waited on was killed by SIGINT; an
+    // ordinary exit 130 means "handled it", and the script carries on. The
+    // exit after it is only the fallback for a signal that does not end us.
+    process.kill(process.pid, signal);
+    process.exit(128 + (os.constants.signals[signal] || 0));
   }
   process.exit(1);
-}
+});