Why the largest number misleads
In a stream that assigns consecutive sequence numbers, the highest number processed is tempting as a completion checkpoint. That shortcut confuses progress with coverage. Suppose processing is complete through 40. Event 41 finishes, event 42 is delayed, and event 43 finishes. The maximum completed number is 43, but the continuous completion boundary remains 41. A notebook offers the same intuition: writing on page 43 does not fill page 42.
Separate observation from completion
Track the highest number observed, the numbers not yet received within the expected range, and the last continuously completed number. Here, 43 is observed, 42 is missing, and completion stops at 41. If 42 arrives but its work fails, that boundary stays unchanged. Advance only after the required effects are durable, then cross already completed successors. Persist effects and completion together where possible, or make retries idempotent. Keep each stream separate; when numbering resets, use a new run identifier.
Run a small practical check
Start from a confirmed boundary of 40. Deliver 41 and 43, finish both, and replay 43. Verify that the duplicate neither advances the boundary past 41 nor repeats committed effects. Now deliver 42, force its work to fail, and inspect the checkpoint again. After a successful retry of 42, the boundary should reach 43. Check persisted state after a restart, not just the displayed number. These examples are illustrative, not reported test results.
Hypothetical boundary: the missing tail
Imagine a batch intended to end at 43, while only 41 and 42 arrive. There is no internal gap to reveal the missing tail. An authoritative end marker declaring 43 makes that omission detectable; silence does not. Decision rule: declare the batch complete only when a trusted endpoint is known and every expected event through it has durably completed. Otherwise report the endpoint as unknown or the declared range as incomplete, even after a timeout.