FAILURE MAP
← Case archive

FA-76730 / Email MIME structure / Member archive

Reassemble message/partial fragments: total agreement · case 05

Fragments that repeat the same total are reported as conflicting.

Member previewVariant 5 · 3 implementations · 7 checks per implementation

Case contract

fragments {id, number, total (optional), body}. Per id: the first fragment with a given number wins; totals seen on fragments must all agree (otherwise "conflict"); without any total the message is "incomplete"; it is "complete" when every number 1..total is present, and its text joins those numbers in order (other numbers are ignored). Result rows [id, status, text or None] sorted by id.

Why this case matters

Large messages split with message/partial must be reassembled exactly once and in order.

One recorded failure

Sample boundary fixture

This sample comes from the broken implementation of a controlled reproducer.

Boundary fixtureActualExpectedOutcome
repeated equal totals[["r", "conflict", null]][["r", "complete", "1523"]]Failed

MEMBER ARCHIVE

The complete case is available to members.

This record includes three runnable implementations, regression fixtures, execution results, and source hashes.

Member access is invitation-based. Sign in with your invited account to inspect the sources.

Sign in to the archive ↗