fix: seven shipped defects in console and network observability

[sanketsudake]

A code review of #13 after it merged found defects that CI and the RFC-scenario tests both passed over. These are live in main, so this is a fix-forward.

Each fix has a regression test proven red first, by stashing the source change and watching it fail.

The two that mattered most

A large binary response body was reported as an empty-but-present body

TruncateText trimmed one byte at a time until the whole string was valid UTF-8 — which only converges when the invalidity sits at the cut boundary. A 100 KB body of 0xFF truncated to "", and the utf8.ValidString guard that exists precisely to skip binary then passed, because "" is valid.

So net --body on a binary response over net_max_body emitted {"response_body": "", "body_truncated": true}, while the same image under the cap correctly said body_unavailable. Identical content, opposite answers, decided by nothing but size.

Validity is now checked on the original payload, and truncation backs off at most utf8.UTFMax-1 bytes instead of rescanning the prefix per byte — the old path burned ~10 ms of quadratic scanning per body, on the daemon's dispatch mutex.

--follow wedged every other command

Streaming dispatch held the daemon's global mutex for its entire window. Measured against the real Serve: a unary call waited 5.000014458s for a live --follow to finish.

RFC-0002 US-2 is literally "watch console output while I exercise the page" — so the feature defeated its own user story. console --follow in one terminal blocked click in another for the whole --timeout.

Streaming dispatch now takes no mutex. The agent deliberately didn't take the "serialise setup, then release" shape I sketched, and I agree with the reasoning: that needs a readiness callback plumbed through chrome.Browser, the stub, *CDP, both daemon halves and the CLI — to serialise two idempotent domain-enable round trips. The mutex exists so multi-step chromedp sequences on one connection don't interleave; a stream isn't that. TestIsStreamMethodCoversEveryStreamingBrowserMethod guards the list against drift.

Two consequences of the same root are fixed with it: the idle timer is now pinged while a stream is alive (a follow longer than the 30-minute window used to be cut silently, EOF, exit 0), and a hung-up client is detected immediately instead of when the daemon next writes.

The review's diagnosis was wrong, and the real bug was bigger

The review said console dropped the pre-attach backlog because Log.entryAdded/javascript was suppressed as a duplicate. Verified empirically against throwaway headless Chrome: Log.enable replayed nothing, and live uncaught exceptions produced no Log.entryAdded/javascript at all — so there was no duplicate to suppress.

The actual cause is in the attach sequence: chromedp issues runtime.Enable(), log.Enable() and network.Enable() before startCapture registers its ListenTarget. The entire backlog, from every source, went on the floor. Registering listeners before chromedp.Run recovers it — and it arrives as Runtime.exceptionThrown, contrary to the review's claim that Runtime doesn't replay.

The source filter is replaced by identity dedupe in a 2s window, so a genuinely recurring error still shows every occurrence.

⚠️ Contract consequence: a --no-daemon read now genuinely sees some history, so buffered: 0 beside a non-empty list would have been incoherent. Both verbs report the real buffered and the note says "partial history" rather than "no retained history". Docs and console --help updated; the VS-10 tests were repurposed rather than deleted.

Redaction gaps

• Hash-router fragments leaked tokens. https://app/#/callback?access_token=SECRET parsed the name as /callback?access_token, which the anchored regex rejected — so the token was emitted verbatim. That is exactly the OAuth implicit flow the fragment handling was added for.
• Location: on a 302 was redacted by nothing — not by name (doesn't match) and not by RedactURL (never applied to header values). URL-valued headers now go through RedactURL rather than being withheld wholesale, so a redirect stays diagnosable.
• Request bodies had no UTF-8 guard at all, so a multipart/form-data image upload became mojibake — precisely what the response-path comment says must not happen.

Bodies are now redacted by default

RFC-0003 only specifies header and URL redaction, so this is a scope decision. The deciding argument is the inconsistency, not the risk in the abstract: ?password=x was already withheld while password=x in a POST body was printed in clear — same secret, opposite answers, decided by nothing but the HTTP method.

Implemented as a structure-preserving rewrite rather than decode/re-encode, because a body cut at the 64 KB cap is no longer parseable and re-encoding would stop the reported payload being the one the page actually sent. Documented limitation: multipart/form-data and other opaque encodings have no field structure to key on and pass through unchanged.

Also

• Per-tab rings were never released. Set.Forget existed, was tested, and had no non-test caller — ~250 KB retained per tab for the daemon's life. Now released on close, including a browser-level targetDestroyed listener for tabs the user closes, which over a long session is most of them.
• pending ignored the caller's filter, so a permanently-open SSE stream made every net --url /api/save report pending >= 1 forever. Now scoped to --url/--method/--type/--since; --status/--failed are deliberately excluded, since an in-flight request has no status and including them would make pending a constant zero for exactly the reads asking about an outcome.
• A quiet --follow emitting zero envelopes is documented, not changed — a terminating summary would be a second envelope shape, and both the skill and session parity depend on one shape per line.

Testing

gofmt, go vet, go test -race ./... clean, including ~108s of live Chrome. The redaction test asserts on the marshalled envelope bytes, not struct fields, so a second unredacted copy riding along in url would still fail it.