IPX replay: durable truncated-frame quarantine is never retracted when the frame later completes #183

New issue

Open

opened 2026-09-05 04:34:18 +00:00 by mara · 0 comments

mara commented

2026-09-05 04:34:18 +00:00

Collaborator

Reviewed at commit 3b4e2da (filed against the IPX replay introduced in 6f40a44, which advances #26).

Problem
An unterminated final frame is quarantined durably (ipx-persist-quarantine with reason "truncated IPX frame", capture-replay.lisp ~lines 190-196) and the checkpoint is intentionally not advanced. That is correct for retry, but the durable quarantine record is never retracted or annotated when the writer later completes the frame and a subsequent replay commits the exchange from the same byte range.

Result
For the same frame range there is both a durable quarantine record and a committed :http-exchange. Consumers of fetch-capture-quarantine-records cannot distinguish a genuine malformed frame from a stale transient-truncation artifact, which erodes trust in quarantine-based alerting.

Repro
Append "{" (no newline) to a spool, replay (quarantine recorded), then append the rest of the frame + newline and replay again: quarantine remains while the exchange commits.

Suggested fix
When a frame starting at an offset that has a durable "truncated" quarantine successfully decodes, retract or supersede that quarantine record (e.g. persist a resolution record, or key quarantine records with a content hash so the truncated stub and the completed frame are linkable). Add a regression test asserting the truncated-then-completed sequence leaves zero unresolved quarantine records.

Reviewed at commit 3b4e2da (filed against the IPX replay introduced in 6f40a44, which advances #26). **Problem** An unterminated final frame is quarantined durably (`ipx-persist-quarantine` with reason "truncated IPX frame", `capture-replay.lisp` ~lines 190-196) and the checkpoint is intentionally not advanced. That is correct for retry, but the durable quarantine record is never retracted or annotated when the writer later completes the frame and a subsequent replay commits the exchange from the same byte range. **Result** For the same frame range there is both a durable quarantine record and a committed `:http-exchange`. Consumers of `fetch-capture-quarantine-records` cannot distinguish a genuine malformed frame from a stale transient-truncation artifact, which erodes trust in quarantine-based alerting. **Repro** Append `"{"` (no newline) to a spool, replay (quarantine recorded), then append the rest of the frame + newline and replay again: quarantine remains while the exchange commits. **Suggested fix** When a frame starting at an offset that has a durable "truncated" quarantine successfully decodes, retract or supersede that quarantine record (e.g. persist a resolution record, or key quarantine records with a content hash so the truncated stub and the completed frame are linkable). Add a regression test asserting the truncated-then-completed sequence leaves zero unresolved quarantine records.

mara added the

bug

label

2026-09-05 04:34:18 +00:00