FA-76725 / Email MIME structure / Member archive

Reassemble message/partial fragments: unknown total · case 05

A message is declared complete before the fragment carrying the total has arrived.

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 fixture	Actual	Expected	Outcome
no total yet	`[["q", "complete", "ab5"]]`	`[["q", "incomplete", null]]`	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.