Transcript/rollout tail scan materializes the whole 64 MiB window

[sumitake]

Raised by the PR review bot on #77 (P2) and deferred there to keep that PR's scope to the change it declares.

Problem

_codex_rollout_window() reads backward in chunks but joins the entire window before returning, and the caller then applies splitlines() to it. For a transcript at or above _CODEX_ROLLOUT_SCAN_LIMIT (64 MiB) that is two large allocations per resolution, even though the qualifying record is normally within the last few KiB.

The coordinator resolves the host profile during both startup_preflight() and issue_policy_envelope(), so a long-running session can pay this cost twice per routed request.

Why it was deferred rather than fixed in #77

_codex_rollout_window is shared with the Codex rollout path. Changing its scan strategy alters behaviour for a second, already-shipped consumer, which is outside what #77 declares and would need its own regression coverage for the Codex side. #77 reuses the helper unchanged precisely so it inherits the existing hardening.

Suggested approach

Scan backward chunk by chunk and stop as soon as the newest qualifying record validates, instead of materializing the full window. Both consumers select the NEWEST matching record, so neither needs the whole window in memory.

Constraints to preserve:

• the incomplete-tail rule (a snapshot whose final record is not newline-terminated must still fail closed);
• the leading partial-line discard when the window is truncated;
• the per-line size cap and strict JSON decoding;
• the post-read fstat identity and size re-check.

A chunk boundary must not be allowed to split a record such that a partial line parses as valid.

Note

Performance only. No correctness or security consequence is claimed, and the current behaviour is bounded — it is a fixed 64 MiB ceiling, not unbounded growth.

[sumitake]

Closing as not worth the risk, on the strength of an adversarial design review rather than a hunch. The plan and review happened before any code was written, per the review-before-codegen rule.

The decision

An incremental backward scan is implementable, but the trade is bad. The benefit is a constant-factor allocation win on an already-bounded path — the 64 MiB ceiling means this was never unbounded growth. The cost is new parser semantics in a reader that gates governance identity for two consumers (the Codex rollout and the Claude transcript), where the failure modes are fail-open rather than loud.

The reviewer (Grok, xAI, read-only architecture) returned RECONSIDER and explicitly declined to soften it: modifications would make a rewrite possible, not worth it.

What the review found in the plan

I proposed proving equivalence by differential testing the generator against the current function as an oracle. That is the right instinct, and the reviewer showed my corpus was insufficient:

• The dangerous half-record is not the one that fails to parse. It is a fragment that alone is valid JSON and passes the same identity predicates as a real record. A differential test only catches that if the fragment is not newline-delimited in the true window — so fixtures must deliberately plant valid-JSON prefixes and suffixes at chunk and truncation boundaries. Generic "record spans two chunks" padding proves nothing.
• Yield ordering and zero-yields-on-raise need their own harness rules; list equality alone does not pin them.
• splitlines() semantics are a trap: it drops the trailing empty after the final newline but keeps interior empties, and interior empties currently reach the decoder and raise. A naive split(b"\n") yields a trailing b"" that does not exist under the oracle, which would newly raise on a well-formed file.
• Property tests at forced chunk sizes (1, 64KiB−1, 64KiB, 64KiB+1) would be required.

That is a materially larger project than this issue's framing suggested.

If this is ever revisited

The minimum bar, from the review — not a blessing, stop-conditions:

1. Incomplete-tail and no-boundary-in-window checked before any yield.
2. Production uses only the generator; the window function becomes a test-only oracle.
3. Full splitlines parity, or an explicit \n-only contract on both sides.
4. Differential plus adversarial fixtures (valid-JSON prefix/suffix at chunk and truncation boundaries), partial-consumption cases, and zero-yields-on-raise.
5. Property-based tests over random JSONL at forced chunk sizes.
6. No change to decoding, predicates, or consumer filters.

Cheaper avenues to try first if this ever becomes measurable: caching the resolved profile across the two startup_preflight() / issue_policy_envelope() calls in one request, or measuring before optimizing. Neither touches the parser.

The current implementation is correct and bounded. Closing.