BitMiracle-AI/Dormice

The problem chart-gaps.ts declares itself the single arbiter of the gap rule, and its header comment says so explicitly: 总览堆叠图与指标 tab 的走势图共用这一条规则:断在哪里只许有一种裁决 (the overview stacked chart and the metrics tab trend chart share this one rule: there may be only one ruling on where a break goes) That is currently false. grep shows only MetricsPanel.tsx imports withGapBreaks; FleetChart.tsx:64-105's toChartRows inlines a clause-for-clause reimplementation of the same algorithm — the same delta/sort/median, the same bucketSeconds-first expected interval, the same 3× threshold, the same midpoint null row. So the same invariant has two arbitration points, and any future adjustment to the gap rule has to be made in both places or the two charts silently diverge. Not a hot path — this is a pure simplification, about 30 lines removed. Proposed solution In toChartRows, map points to ChartRow as it does now, then delegate: return with

The problem GET /v2/sandboxes re-reads the runtime settings from SQLite once per row in the response. infoView (control.ts:203-227) opens with: const { sandboxDefaults } = readRuntimeSettings(db); which is a real drizzle SELECT plus view conversion (settings.ts:75-87). The list route (control.ts:649) maps infoView over the whole page, and limit goes up to 1000 (control.ts:87) — so a polled endpoint runs the same query up to 1000 times per request for a value that is per-daemon and identical for every row. Honest about the magnitude: the repo's own comments measure point reads in microseconds, so the worst case is roughly 1 ms on a 1000-row request, and the route's real cost is dominated by listSandboxes and the per-row JSON.parse. It is genuinely removable duplicate work, but the size of the win is marginal — filing it as a cleanup rather than a performance fix. Proposed solution Read once per request and pass it down: const { sandboxDefaults } = readRuntimeSettings(db) in the /v2/

The problem The SDK double-encodes string file content: TextEncoder.encode allocates a Uint8Array, then Buffer.from copies it a second time before base64. // packages/sdk/src/client.ts:583-588 (and :605-610 in writeFile) contentBase64: Buffer.from( typeof file.content === 'string' ? new TextEncoder().encode(file.content) : file.content, ).toString('base64'), Buffer.from(string) is UTF-8 encoding, and Buffer.from(Uint8Array) is the copy the code already makes — so the TextEncoder and the ternary only reimplement what Buffer.from does natively. On the file-push hot path (up to 16 MiB per file, 32 MiB decoded per batch) that is one redundant full-content allocation plus memcpy per string file. Proposed solution contentBase64: Buffer.from(file.content).toString('base64') (and Buffer.from(content) in writeFile) — the string | Uint8Array union is exactly Buffer.from's own overload set. Checked before proposing: Types: the union compiles under the repo's strict + noUncheckedInd

The problem resolvePortTarget inspects the same container twice, and the first inspect already carried the answer. // packages/server/src/executor/docker.ts:429-430 const containerId = await this.expectState(sandboxId, 'running'); const info = await this.docker.getContainer(containerId).inspect(); expectState (:1429-1450) performs a full ContainerInspect and returns only info.Id; the very next line inspects the same container again to read NetworkSettings — data the first call already had in hand. The caller is sandbox-proxy's resolveTarget, which runs once per proxied HTTP request and once per upgrade. That makes this the hottest observation verb after exec, and it doubles the engine round-trips for it: one extra engine round-trip plus a few KB of JSON parsing on every proxied connection. Proposed solution Have expectState return the full inspect payload (Promise<Docker.ContainerInspectInfo>, or { id, info }). The 16 existing call sites keep using info.Id; resolvePortTarget reads Ne

What happened dor sandbox exec -t parses its argument with a bare Number(), so a non-numeric value becomes NaN and the command dies with an internal AbortSignal error that never mentions the flag. $ dor sandbox exec my-key 'sleep 600' -t 10m dor: The value of "delay" is out of range. It must be an integer. Received NaN // packages/cli/src/main.ts:68-72 .option( '-t, --timeout <seconds>', 'kill the command after this many seconds', (value: string) => Number(value), ) NaN is not nullish, so the ?? DEFAULT at client.ts:552-553 does not apply; timeoutMs becomes NaN and AbortSignal.timeout(NaN) (client.ts:657) throws. Reproduced on Node 26. Expected: a typo in a flag is named at the flag — the standard clientFromEnv sets for itself, naming a missing variable right there rather than letting it surface later as a confusing error. Got: an undici/AbortSignal implementation detail, and the command is refused before any request is made. No state damage. commands.test.ts has no coverage of