@desplega.ai/agent-swarm 1.131.0 → 1.133.1

package/src/http/db-query-bounded.ts

@@ -0,0 +1,313 @@
+/**
+ * Bounded db-query execution — Fix 1 for the API event-loop freeze.
+ *
+ * `bun:sqlite` is synchronous and exposes no interrupt, progress handler, or
+ * statement timeout (verified two ways — see the design doc referenced from
+ * the PR). A single expensive query therefore blocks the whole API process
+ * until SQLite finishes. Running the query in a short-lived child process
+ * lets the parent SIGKILL it on a wall-clock budget: the child dies and its
+ * CPU is reclaimed immediately, unlike a worker thread's `terminate()`,
+ * which detaches the main thread's view of the worker but leaves the native
+ * SQLite call running to completion.
+ *
+ * SQL and params travel over the child's stdin (not argv), so query text
+ * never appears in `ps` output. The child opens its own read-only
+ * connection to the same on-disk WAL database file and loads the
+ * sqlite-vec extension itself, from the same path the parent process uses
+ * (env var first, npm resolver fallback in dev) — the child cannot see the
+ * parent's already-loaded extension across the process boundary.
+ *
+ * `maxRows` travels in the same payload and is applied in the child, before
+ * `rowArrays` is built and written to stdout — a query against a huge table
+ * with a small `maxRows` transfers and parses a payload bounded by
+ * `maxRows`, not by the full match count. `total` still reports every row
+ * SQLite matched, so truncation is still detectable by comparing the two.
+ *
+ * If no `bun` executable can be spawned at all (no separate Bun CLI on
+ * $PATH), the query falls back to the synchronous in-process path instead
+ * of failing outright — see runBoundedQueryChild's catch around Bun.spawn.
+ *
+ * The child's own connection sets `PRAGMA busy_timeout` to the same
+ * `budgetMs` the parent uses for its SIGKILL timer, not a fixed value — a
+ * lock wait that would out-wait the overall budget anyway should surface as
+ * SQLite's own busy error (or the parent's timeout) rather than waiting
+ * longer than the query could ever be allowed to run.
+ */
+
+import { getDb, resolveSqliteVecExtensionPath } from "../be/db";
+import type { DbQueryResult } from "./db-query-shared";
+import {
+  assertSingleStatement,
+  DbQueryConcurrencyCapError,
+  DbQueryTimeoutError,
+  executeReadOnlyQuery,
+  getDbQueryConcurrencyCap,
+  warnDbQuerySpawnUnavailableOnce,
+} from "./db-query-shared";
+
+interface ChildPayload {
+  file: string;
+  sql: string;
+  params: unknown[];
+  vecExtensionPath?: string;
+  maxRows?: number;
+  busyTimeoutMs: number;
+}
+
+interface ChildSuccess {
+  columns: string[];
+  rows: unknown[][];
+  elapsed: number;
+  total: number;
+}
+
+/** Exit code the child uses when the query is a write statement. */
+const WRITE_REJECTED_EXIT_CODE = 2;
+
+// Plain JS (no TypeScript syntax) — this string is executed directly by
+// `bun -e`, not compiled first. Mirrors executeReadOnlyQuery's read-only
+// guard exactly, so `total` keeps meaning "rows SQLite actually returned"
+// regardless of which path ran the query.
+//
+// Iterates the statement rather than calling `stmt.all()` — Codex review,
+// PR #1192 thread 3815922598: `stmt.all()` still materializes every matching
+// row as a JS object before anything gets to look at `maxRows`, even though
+// the earlier fix already bounded what crosses the child/parent boundary.
+// Iterating keeps that same boundary bound, but only ever holds one row
+// object at a time plus the (at most `maxRows`) retained arrays — a query
+// against a huge table with a small `maxRows` no longer allocates one JS
+// object per matched row just to discard almost all of them. `total` is
+// still incremented for every row visited, so truncation stays detectable
+// by comparing it against `rows.length`.
+//
+// BLOB columns (e.g. memories.embedding, script_embeddings.embedding) come
+// back from bun:sqlite as a Uint8Array — Codex review, PR #1192 thread
+// 3816302384. JSON.stringify on a Uint8Array serializes it as an indexed
+// object ({"0":1,"1":2,...}), not an array, because TypedArrays have no
+// toJSON and JSON.stringify only special-cases real Arrays. The parent's
+// JSON.parse then hands the MCP table renderer that indexed object, and its
+// `String(v)` prints "[object Object]" instead of the byte list "1,2,3" the
+// pre-child-process path produced. Converting to a plain Array here keeps
+// `String()` on the round-tripped value identical to `String()` on the
+// original Uint8Array (both join with commas) — the fix belongs in the
+// child, once, rather than every consumer of DbQueryResult guessing which
+// columns might be BLOBs.
+const CHILD_SCRIPT = `
+const { Database } = require("bun:sqlite");
+
+(async () => {
+  let payload = "";
+  for await (const chunk of Bun.stdin.stream()) {
+    payload += Buffer.from(chunk).toString("utf8");
+  }
+
+  const { file, sql, params, vecExtensionPath, maxRows, busyTimeoutMs } = JSON.parse(payload);
+
+  try {
+    const db = new Database(file, { readonly: true });
+    // Bound by the same wall-clock budget the parent uses for its SIGKILL
+    // timer, not a fixed value — a lock wait that would out-wait the overall
+    // budget anyway should surface as SQLite's own busy error (or the
+    // parent's timeout) rather than waiting longer than the query could ever
+    // be allowed to run.
+    db.exec("PRAGMA busy_timeout = " + Math.trunc(busyTimeoutMs) + ";");
+    if (vecExtensionPath) {
+      try {
+        db.loadExtension(vecExtensionPath);
+      } catch {
+        // Non-fatal: only queries that reference vec0 tables/functions need it.
+      }
+    }
+
+    const stmt = db.prepare(sql);
+    if (stmt.columnNames.length === 0) {
+      process.stderr.write("Only read-only queries are allowed");
+      process.exit(${WRITE_REJECTED_EXIT_CODE});
+    }
+
+    const columns = stmt.columnNames;
+    const start = performance.now();
+    const rowArrays = [];
+    let total = 0;
+    for (const row of stmt.iterate(...(params || []))) {
+      total++;
+      if (!maxRows || rowArrays.length < maxRows) {
+        rowArrays.push(
+          columns.map((col) => {
+            const value = row[col];
+            return value instanceof Uint8Array ? Array.from(value) : value;
+          }),
+        );
+      }
+    }
+    const elapsed = Math.round(performance.now() - start);
+
+    process.stdout.write(JSON.stringify({ columns, rows: rowArrays, elapsed, total }));
+  } catch (err) {
+    process.stderr.write(err && err.message ? err.message : String(err));
+    process.exit(1);
+  }
+})();
+`;
+
+/**
+ * Concurrency cap for in-flight bounded child-process queries.
+ *
+ * Before this cap, N concurrent callers spawned N children in parallel, each
+ * materializing its own full result set — peak memory went from roughly 1x
+ * (the old synchronous path serialized callers on one thread) to roughly
+ * 3x-per-query and unbounded in N (the child's own rows array, the parent's
+ * raw stdout buffer, and the parent's parsed JS object all live at once per
+ * in-flight query).
+ *
+ * The default is `DB_QUERY_CONCURRENCY_CAP_DEFAULT` (see db-query-shared.ts
+ * for the sizing math against the API pod's real 1 GiB memory limit);
+ * overridable per deployment via `DB_QUERY_CONCURRENCY_CAP`, read dynamically
+ * on every call (never captured in a module-level const) so a `swarm_config`
+ * edit takes effect on the next request with no restart — mirrors
+ * `isDbQueryBoundedEnabled`. Rejects immediately when full rather than
+ * queueing — an unbounded queue would just move the memory growth from "many
+ * children" to "many pending callers," and a caller that's told to retry can
+ * back off, whereas a caller stuck in an in-process queue can't.
+ */
+let activeBoundedQueryCount = 0;
+
+function acquireBoundedQuerySlot(): void {
+  const cap = getDbQueryConcurrencyCap();
+  if (activeBoundedQueryCount >= cap) {
+    throw new DbQueryConcurrencyCapError(
+      `Too many concurrent db-query executions in flight (cap ${cap}). Retry shortly.`,
+    );
+  }
+  activeBoundedQueryCount++;
+}
+
+function releaseBoundedQuerySlot(): void {
+  activeBoundedQueryCount--;
+}
+
+/**
+ * Run one read-only query in a bounded `bun -e` child process, SIGKILLing it
+ * if it runs past `budgetMs`. `total` semantics match executeReadOnlyQuery
+ * exactly: the child visits every matching row to count `total`, but only
+ * converts and serializes the first `maxRows` of them (in the child, see
+ * CHILD_SCRIPT), so `total` still means "rows SQLite returned," not "rows
+ * delivered" (callers such as src/tools/db-query.ts:41 and
+ * src/http/metrics.ts:168 compare the two to decide whether a result was
+ * truncated).
+ */
+export async function executeReadOnlyQueryBounded(
+  sql: string,
+  params: unknown[] = [],
+  budgetMs: number,
+  maxRows?: number,
+): Promise<DbQueryResult> {
+  assertSingleStatement(sql);
+  acquireBoundedQuerySlot();
+
+  try {
+    return await runBoundedQueryChild(sql, params, budgetMs, maxRows);
+  } finally {
+    releaseBoundedQuerySlot();
+  }
+}
+
+/**
+ * Whether a fired timer should be reported to the caller as a timeout.
+ *
+ * A complete, correct result can land in the same tick the budget timer
+ * fires — the SIGKILL is a no-op on an already-exited child, and its stdout
+ * is still the real answer. Only report a timeout when the kill genuinely
+ * prevented a clean result (no successful, non-empty stdout); pulled out as
+ * its own function so both halves of the condition can be pinned directly in
+ * tests instead of only through process-timing races.
+ */
+export function isReportableTimeout(timedOut: boolean, exitCode: number, stdout: string): boolean {
+  return timedOut && !(exitCode === 0 && stdout.length > 0);
+}
+
+async function runBoundedQueryChild(
+  sql: string,
+  params: unknown[],
+  budgetMs: number,
+  maxRows?: number,
+): Promise<DbQueryResult> {
+  const payload: ChildPayload = {
+    file: getDb().filename,
+    sql,
+    params,
+    vecExtensionPath: resolveSqliteVecExtensionPath(),
+    maxRows,
+    busyTimeoutMs: budgetMs,
+  };
+
+  let proc: Bun.Subprocess<"pipe", "pipe", "pipe">;
+  try {
+    proc = Bun.spawn(["bun", "-e", CHILD_SCRIPT], {
+      stdin: "pipe",
+      stdout: "pipe",
+      stderr: "pipe",
+    });
+  } catch (err) {
+    // No `bun` executable resolvable on $PATH to spawn as a child — e.g. the
+    // standalone `dist/agent-swarm` binary, which embeds the Bun runtime for
+    // its own execution but does not bundle a separate spawnable `bun`
+    // binary. Every other documented deployment surface (Docker, npm/bunx,
+    // the systemd installer) ships or requires `bun` on $PATH, so this is
+    // expected to be rare; fall back to the in-process path rather than
+    // failing every db-query outright.
+    const message = err instanceof Error ? err.message : String(err);
+    if (!/executable not found/i.test(message) && !/enoent/i.test(message)) {
+      throw err;
+    }
+    warnDbQuerySpawnUnavailableOnce();
+    return executeReadOnlyQuery(sql, params, maxRows);
+  }
+
+  proc.stdin.write(JSON.stringify(payload));
+  await proc.stdin.end();
+
+  let timedOut = false;
+  const timer = setTimeout(() => {
+    timedOut = true;
+    proc.kill("SIGKILL");
+  }, budgetMs);
+
+  let stdout: string;
+  let stderr: string;
+  let exitCode: number;
+  try {
+    [stdout, stderr, exitCode] = await Promise.all([
+      new Response(proc.stdout).text(),
+      new Response(proc.stderr).text(),
+      proc.exited,
+    ]);
+  } finally {
+    clearTimeout(timer);
+  }
+
+  if (isReportableTimeout(timedOut, exitCode, stdout)) {
+    throw new DbQueryTimeoutError(
+      `Query exceeded the ${budgetMs}ms budget and was terminated. Filter on an indexed column and add a LIMIT. Aggregates such as COUNT(*), SUM(...) or typeof() over session_logs, agent_log, events or task_context_snapshots read every row in range and cannot be made cheap by chunking on rowid.`,
+    );
+  }
+
+  if (exitCode === WRITE_REJECTED_EXIT_CODE) {
+    throw new Error(stderr.trim() || "Only read-only queries are allowed");
+  }
+
+  if (exitCode !== 0) {
+    throw new Error(stderr.trim() || `Query failed with exit code ${exitCode}`);
+  }
+
+  // The child already applies maxRows before serializing (see CHILD_SCRIPT) —
+  // parsed.rows is already capped, so no second slice is needed here.
+  const parsed = JSON.parse(stdout) as ChildSuccess;
+
+  return {
+    columns: parsed.columns,
+    rows: parsed.rows,
+    elapsed: parsed.elapsed,
+    total: parsed.total,
+  };
+}

package/src/http/db-query-shared.ts

@@ -0,0 +1,249 @@
+/**
+ * Primitives shared between the synchronous db-query path (db-query.ts) and
+ * the bounded child-process path (db-query-bounded.ts). Split out to avoid a
+ * circular import: db-query.ts's HTTP handler calls into the bounded
+ * executor, and the bounded executor reuses the same single-statement guard.
+ *
+ * Also holds the Fix-1 operator knobs (the `DB_QUERY_*` kill switch and
+ * budget/row overrides), since both db-query.ts (HTTP) and tools/db-query.ts
+ * (MCP) need to read them without importing each other.
+ */
+
+import { getDb } from "../be/db";
+import { isEnvFlagEnabled } from "../utils/env-flag";
+
+export interface DbQueryResult {
+  columns: string[];
+  rows: unknown[][];
+  elapsed: number;
+  total: number;
+}
+
+/**
+ * Thrown when a bounded query is killed after exceeding its wall-clock
+ * budget. A distinct class (not a plain `Error`) so `handleDbQuery` can
+ * return a documented, machine-readable status instead of a generic 400.
+ */
+export class DbQueryTimeoutError extends Error {
+  constructor(message: string) {
+    super(message);
+    this.name = "DbQueryTimeoutError";
+  }
+}
+
+/**
+ * Thrown when `DB_QUERY_CONCURRENCY_CAP` in-flight bounded queries are
+ * already running. A distinct class so `handleDbQuery` can return 429 with
+ * retry guidance instead of a generic 400 — the caller isn't wrong, the
+ * server is just saturated right now.
+ */
+export class DbQueryConcurrencyCapError extends Error {
+  constructor(message: string) {
+    super(message);
+    this.name = "DbQueryConcurrencyCapError";
+  }
+}
+
+export function stripTrailingSemicolon(sql: string): string {
+  return sql.trim().replace(/;\s*$/, "").trim();
+}
+
+export function assertSingleStatement(sql: string): void {
+  const stripped = stripTrailingSemicolon(sql);
+  if (stripped.includes(";")) {
+    throw new Error("Only one SQL statement is allowed");
+  }
+}
+
+/**
+ * Execute a read-only SQL query against the swarm database, synchronously,
+ * on the caller's own thread.
+ *
+ * Lives here (not db-query.ts) so db-query-bounded.ts can fall back to it
+ * without a circular import — db-query.ts already imports the bounded
+ * executor. Two callers rely on this fallback path: the
+ * `DB_QUERY_BOUNDED_ENABLED=false` kill switch, and runBoundedQueryChild when
+ * no `bun` executable can be spawned (see warnDbQuerySpawnUnavailableOnce).
+ */
+export function executeReadOnlyQuery(
+  sql: string,
+  params: unknown[] = [],
+  maxRows?: number,
+): DbQueryResult {
+  assertSingleStatement(sql);
+  const stmt = getDb().prepare(sql);
+
+  // bun:sqlite: columnNames is empty for write statements, populated for SELECT/PRAGMA/EXPLAIN
+  if (stmt.columnNames.length === 0) {
+    throw new Error("Only read-only queries are allowed");
+  }
+
+  const columns = stmt.columnNames as string[];
+  const start = performance.now();
+  // Iterate rather than `stmt.all()` + slice: a query against a huge table
+  // with a small maxRows would otherwise hold every matched row's object in
+  // memory at once just to throw most of them away. Iterating still visits
+  // every row (so `total` keeps meaning "rows SQLite matched"), but only the
+  // first `maxRows` are converted and retained.
+  const rowArrays: unknown[][] = [];
+  let total = 0;
+  for (const row of stmt.iterate(...(params as [string]))) {
+    total++;
+    if (maxRows === undefined || rowArrays.length < maxRows) {
+      rowArrays.push(columns.map((col) => (row as Record<string, unknown>)[col]));
+    }
+  }
+  const elapsed = Math.round(performance.now() - start);
+
+  return { columns, rows: rowArrays, elapsed, total };
+}
+
+/** Hardcoded pre-flag defaults — kept equal to the values PR #87 shipped with, so adding the flag changes no behaviour out of the box. */
+export const DB_QUERY_HTTP_BUDGET_MS_DEFAULT = 10_000;
+export const DB_QUERY_HTTP_MAX_ROWS_DEFAULT = 1000;
+export const DB_QUERY_MCP_BUDGET_MS_DEFAULT = 5_000;
+export const DB_QUERY_MCP_MAX_ROWS_DEFAULT = 100;
+
+/**
+ * Default concurrency cap for in-flight bounded child-process queries (see
+ * `acquireBoundedQuerySlot` in db-query-bounded.ts).
+ *
+ * Codex review, PR #1192 thread 3816146995: the deployment guide's real API
+ * memory limit is 1 GiB (`docs-site/.../guides/performance-resource-sizing.mdx`
+ * — the `10Gi` size in `charts/agent-swarm/values.yaml` is PVC storage, not a
+ * memory limit). Sized against the largest payload measured against this code
+ * path — a 68MB result set — and a ~3x-per-query worst-case footprint (the
+ * child's own rows array, the parent's raw stdout buffer, and the parent's
+ * parsed JS object all live at once per in-flight query, ~200MB): a cap of 3
+ * bounds worst-case fan-out to ~600MB, leaving headroom in the 1 GiB limit for
+ * the API process's own baseline footprint. Configurable via
+ * `DB_QUERY_CONCURRENCY_CAP` for operators running a larger API pod.
+ */
+export const DB_QUERY_CONCURRENCY_CAP_DEFAULT = 3;
+
+/**
+ * Master kill switch for the bounded child-process execution path (Fix 1).
+ * Enabled by default — the fix ships active; an operator sets this to
+ * `false` to restore the pre-fix synchronous, unbounded path. Read
+ * dynamically on every call (never captured in a module-level const) so a
+ * `swarm_config` edit takes effect on the next request with no restart —
+ * mirrors `isSteeringEnabled` / `isPoolAffinityEnforcementEnabled`.
+ */
+export function isDbQueryBoundedEnabled(env: NodeJS.ProcessEnv = process.env): boolean {
+  return isEnvFlagEnabled("DB_QUERY_BOUNDED_ENABLED", true, env);
+}
+
+/**
+ * Node/Bun's `setTimeout` takes a 32-bit signed delay internally; a value
+ * above this silently wraps instead of waiting that long (observed as the
+ * timer firing almost immediately). A budget read from an env var must never
+ * cross it. See https://nodejs.org/api/timers.html#settimeoutcallback-delay-args.
+ */
+export const MAX_TIMER_DELAY_MS = 2_147_483_647;
+
+/**
+ * Read a positive-integer override, falling back to `defaultValue` for
+ * anything absent, non-integer (including fractions — `"500.5"` is rejected,
+ * not truncated to 500), <= 0, or above `maxValue`. Mirrors the `^\d+$`
+ * integer check `integerValidators` in swarm-config-guard.ts applies to the
+ * same keys when set via `swarm_config` — this function is the path that
+ * check does NOT cover, since these getters read `process.env` directly.
+ */
+function readPositiveIntEnv(
+  key: string,
+  defaultValue: number,
+  env: NodeJS.ProcessEnv = process.env,
+  maxValue: number = Number.MAX_SAFE_INTEGER,
+): number {
+  const raw = env[key];
+  if (raw === undefined) return defaultValue;
+  const trimmed = raw.trim();
+  if (!/^\d+$/.test(trimmed)) return defaultValue;
+  const parsed = Number(trimmed);
+  if (!Number.isSafeInteger(parsed) || parsed <= 0 || parsed > maxValue) return defaultValue;
+  return parsed;
+}
+
+/** Wall-clock budget for `/api/db-query`. Overridable via `DB_QUERY_HTTP_BUDGET_MS`. */
+export function getDbQueryHttpBudgetMs(env: NodeJS.ProcessEnv = process.env): number {
+  return readPositiveIntEnv(
+    "DB_QUERY_HTTP_BUDGET_MS",
+    DB_QUERY_HTTP_BUDGET_MS_DEFAULT,
+    env,
+    MAX_TIMER_DELAY_MS,
+  );
+}
+
+/** Row cap for `/api/db-query`. Overridable via `DB_QUERY_HTTP_MAX_ROWS`. */
+export function getDbQueryHttpMaxRows(env: NodeJS.ProcessEnv = process.env): number {
+  return readPositiveIntEnv("DB_QUERY_HTTP_MAX_ROWS", DB_QUERY_HTTP_MAX_ROWS_DEFAULT, env);
+}
+
+/** Wall-clock budget for the MCP `db-query` tool. Overridable via `DB_QUERY_MCP_BUDGET_MS`. */
+export function getDbQueryMcpBudgetMs(env: NodeJS.ProcessEnv = process.env): number {
+  return readPositiveIntEnv(
+    "DB_QUERY_MCP_BUDGET_MS",
+    DB_QUERY_MCP_BUDGET_MS_DEFAULT,
+    env,
+    MAX_TIMER_DELAY_MS,
+  );
+}
+
+/** Concurrency cap for in-flight bounded child-process queries. Overridable via `DB_QUERY_CONCURRENCY_CAP`. */
+export function getDbQueryConcurrencyCap(env: NodeJS.ProcessEnv = process.env): number {
+  return readPositiveIntEnv("DB_QUERY_CONCURRENCY_CAP", DB_QUERY_CONCURRENCY_CAP_DEFAULT, env);
+}
+
+/** Row cap for the MCP `db-query` tool. Overridable via `DB_QUERY_MCP_MAX_ROWS`. */
+export function getDbQueryMcpMaxRows(env: NodeJS.ProcessEnv = process.env): number {
+  return readPositiveIntEnv("DB_QUERY_MCP_MAX_ROWS", DB_QUERY_MCP_MAX_ROWS_DEFAULT, env);
+}
+
+let hasWarnedBoundedDisabled = false;
+let hasWarnedSpawnUnavailable = false;
+
+/** Exposed for tests only — resets the one-time warning between cases. */
+export function resetDbQueryBoundedWarningForTests(): void {
+  hasWarnedBoundedDisabled = false;
+}
+
+/** Exposed for tests only — resets the one-time warning between cases. */
+export function resetDbQuerySpawnUnavailableWarningForTests(): void {
+  hasWarnedSpawnUnavailable = false;
+}
+
+/**
+ * Logs once per process the first time a query runs the legacy unbounded
+ * path because `DB_QUERY_BOUNDED_ENABLED=false`. An operator can turn the
+ * protection off, but not silently — this is the trace that they did.
+ */
+export function warnDbQueryBoundedDisabledOnce(): void {
+  if (hasWarnedBoundedDisabled) return;
+  hasWarnedBoundedDisabled = true;
+  console.warn(
+    "[db-query] DB_QUERY_BOUNDED_ENABLED=false — db-query timeout protection is disabled. " +
+      "Queries now run in-process with no wall-clock budget and can freeze the API event loop " +
+      "until they finish. Set DB_QUERY_BOUNDED_ENABLED=true (or delete the override) to restore " +
+      "the bounded child-process path.",
+  );
+}
+
+/**
+ * Logs once per process the first time the bounded path can't spawn a `bun`
+ * executable at all (no separate Bun CLI on $PATH — e.g. the standalone
+ * `dist/agent-swarm` binary built by `bun run build:binary`, which embeds
+ * the Bun runtime for its own execution but does not bundle a
+ * spawnable `bun` binary alongside it). Every other documented deployment
+ * path (Docker images, npm/bunx, the systemd installer) ships or requires a
+ * separate `bun` CLI, so this is expected to be rare.
+ */
+export function warnDbQuerySpawnUnavailableOnce(): void {
+  if (hasWarnedSpawnUnavailable) return;
+  hasWarnedSpawnUnavailable = true;
+  console.warn(
+    "[db-query] No spawnable `bun` executable found on $PATH — db-query timeout protection is " +
+      "unavailable on this host. Falling back to the in-process path with no wall-clock budget; " +
+      "queries can freeze the API event loop until they finish. Install the `bun` CLI alongside " +
+      "this process to restore the bounded child-process path.",
+  );
+}