Files
orca/src/shared
Neil 6b1cbe54a1 fix(process-table): fail a short ps capture loudly, and stop a resume spending 49 of them (#18166)
The POSIX process-table capture ran `execFile('ps', ...)` with no `maxBuffer`,
inheriting Node's 1MB default. Measured at 1,460 processes the capture is 326KB
with a 5,116-char longest row — ~3x headroom, which a busy host clears.

Two separate defects follow, fixed here:

1. `parseProcessTableRows` drops unparseable lines, so any short capture reads
   as a COMPLETE table whose missing processes simply are not running. Verified:
   a capture cut at 4KB parses to 59 of 1,463 rows, and an empty capture parses
   to `[]`, both with no error — and `resolveAgentForegroundProcessWithAvailability`
   then answers `available: true`. That is the `unverifiable` -> `exited` collapse
   the execution boundary forbids. The capture now rejects with
   `ProcessTableCaptureError` on a ceiling-length or row-less capture, so both the
   lenient and strict views fail loudly and callers report unavailable.

2. `maxBuffer` is now an explicit 32MB, matching the sibling reader in
   `pty-descendant-termination.ts` and its stated reasoning. Without it a 4,000-
   process host fails EVERY capture, degrading the whole subsystem permanently.

Separately, `readStructuredTuiProcessIdentity` polled a fresh whole-machine `ps`
every 50ms for up to 5s. Each capture costs ~0.065 CPU-s, and the 5s ceiling is
only reached when the child never appears — where the tight interval buys
nothing. The interval now holds at 50ms for the first second, then doubles to a
500ms cap. Identification latency is unchanged for any child appearing inside
that window, and the 5s ceiling is unchanged.
2026-09-02 13:22:25 -07:00
..
2026-09-02 11:00:24 -07:00
2026-05-31 05:55:04 -07:00