Your test asserts a group's total is 7, but sees that group emitted twice with different values — what is wrong with the assertion?

## Why one group can produce several outputs The assumption inside `assert total == 7` is that a group emits once, when it is done. That is one design among several, and the family of engines in this class genuinely disagrees: - **Emit once on settling.** The group produces nothing until the running claim that no older record will arrive has passed its end, then one value. - **Emit early, then correct.** The job publishes a provisional value for latency, and revises it as more records land, including after the group settles if a late record is allowed to re-open it. - **Emit a running value.** Every input updates the group's result and the update itself is the output, so the number of emissions is the number of records. And separately from the contract, **recovery can repeat an emission**. A job that promises its effects happen at least once may, after a failure, re-produce output it had already produced. That is a repeat, not a revision, and it looks nothing like a bug in the aggregate. ## Why the failing assertion looks right `assert total == 7` reads like a statement about arithmetic, which is why it survives review. It is actually a statement about three things at once: the arithmetic, the emission contract, and the moment of observation. Only the first is what the author meant to assert. When the job is later put onto early emission for latency reasons — a change that leaves every settled value identical — the assertion fails, and the team learns the wrong lesson from a red test. ## What to assert instead 1. **Collect, do not sample.** Record every emission with its group key, its value, and where the completeness claim stood when it appeared. The collected sequence is the observable, not any single value. 2. **Assert the settled value.** After advancing the claim past the group's end and feeding nothing further, the last emission for that group is 7. This holds under all three contracts for any group that emitted at all. 3. **Assert the shape of the intermediate emissions, if at all.** Under a sum of non-negative amounts they are non-decreasing; under a distinct count, non-decreasing; under an average, nothing useful, and knowing that is itself worth writing down. 4. **Tolerate exact repeats.** An identical value appearing twice with no input in between is what at-least-once delivery looks like, and should fail the test only if the job's contract forbids it. 5. **Name the contract in the test.** A test called `settles_at_seven_after_claim_passes` says what it protects; one called `total_is_seven` does not. ## Revision against repeat | | Revision | Repeat | |---|---|---| | The value | Different from the previous emission | Identical to the previous emission | | What caused it | Further input, or the claim moving | The same output produced again after a failure | | What the consumer needs | An update keyed by group, not an append | An idempotent write, or its own deduplication | | What the test does | Expect it; assert the last one | Tolerate it; assert it did not change the settled value | Recording the claim position alongside each emission is what makes the two separable in the collected sequence: a revision follows new input or a claim advance, a repeat follows neither. ## The assertion tells you what the consumer must be This is the part that makes the question a senior one. If the test had to tolerate revisions, then so must whatever reads the output. A consumer that appends every emission double-counts the moment a group is revised; it needs an update keyed by group instead. A test written as a single final value quietly assumes an append-only consumer that the job never promised to feed, and the mismatch surfaces in production as totals that are too high and impossible to reproduce from a fixture. Writing the assertion honestly forces the contract question into the open while it is still cheap. ## What survives a change of contract One assertion holds across all three designs for any group that produces output at all: after the claim has passed the group's end and no further records have been fed, the group's latest value is the expected one. Everything stronger than that — that there was exactly one emission, that no provisional value appeared, that the value never moved — is an assertion about the runtime's configuration rather than about the logic, and belongs in a separate, clearly named test that someone can delete when the configuration deliberately changes.