Capture process stdout/stderr goes to interactive stdio; mitmdump diagnostics invisible #187

New issue

Closed

opened 2026-09-05 04:35:20 +00:00 by mara · 0 comments

mara commented

2026-09-05 04:35:20 +00:00

Collaborator

Reviewed at commit 3b4e2da (filed against capture wiring from 40389ab, mitmdump lifecycle #147; interacts with replay from 6f40a44).

Problem
default-capture-process-runner (source/hackmode-core/capture-provider.lisp ~lines 80-92) spawns mitmdump with :output :interactive and :error-output :interactive. In a long-lived operation this leaves the capture subprocess writing to the Lisp image's stdio, and mitmdump's stderr diagnostics (TLS errors, addon RuntimeError for missing IPX options, proxy bind failures) are not captured anywhere structured.

Impact

note-capture-process-exit sees only exit codes; a mitmdump that dies at startup because of a bad option or addon load failure is indistinguishable from a clean stop.
Operator-facing interactivity suffers: noisy capture output interleaves with the LISH/REPL stream.

Suggested fix
Redirect subprocess output to operation-scoped log files (e.g. under the same directory as the spool path, capture-<session-id>.log) and surface the tail of that log in capture-service error state (capture-service-last-error), or expose it through the typed capture service state. Add a test asserting a mitmdump startup failure is observable through the typed service state.

Also note the addon raises RuntimeError in running() when required IPX options are missing (tools/ipx/mitmproxy-addon.py); with :error-output :interactive the operator will never see why capture silently produced no spool.

Reviewed at commit 3b4e2da (filed against capture wiring from 40389ab, mitmdump lifecycle #147; interacts with replay from 6f40a44). **Problem** `default-capture-process-runner` (`source/hackmode-core/capture-provider.lisp` ~lines 80-92) spawns `mitmdump` with `:output :interactive` and `:error-output :interactive`. In a long-lived operation this leaves the capture subprocess writing to the Lisp image's stdio, and mitmdump's stderr diagnostics (TLS errors, addon RuntimeError for missing IPX options, proxy bind failures) are not captured anywhere structured. **Impact** 1. `note-capture-process-exit` sees only exit codes; a mitmdump that dies at startup because of a bad option or addon load failure is indistinguishable from a clean stop. 2. Operator-facing interactivity suffers: noisy capture output interleaves with the LISH/REPL stream. **Suggested fix** Redirect subprocess output to operation-scoped log files (e.g. under the same directory as the spool path, `capture-<session-id>.log`) and surface the tail of that log in capture-service error state (`capture-service-last-error`), or expose it through the typed capture service state. Add a test asserting a mitmdump startup failure is observable through the typed service state. Also note the addon raises `RuntimeError` in `running()` when required IPX options are missing (`tools/ipx/mitmproxy-addon.py`); with `:error-output :interactive` the operator will never see why capture silently produced no spool.

mara added the

refactor

label

2026-09-05 04:35:20 +00:00