Current outcome
Keep the first example honest about grouping and ordering when batches can complete concurrently.
Replanned on 2026-09-06 against GoBatch master 63ef757 and ShitQuant's recorder, enrichment, paper/replay, and flow workloads. This is an implementation target, not a claim that the behavior already exists.
Required behavior
Verification and completion
Run the example with a controlled finite input and verify its stated guarantees. If order may vary, assert values/counts rather than an unsupported exact sequence.
Follow the repository's formatting, race-test, vet/lint, package documentation, example and changelog requirements for the changed surface. Report the actual supported behavior and migration; do not treat a passing coverage percentage as proof of these outcomes.
Scope and relationships
Can be fixed independently and coordinated with #84; no prerequisite on unrelated PR merges.
Design history
The earlier report/prototype remains below for provenance; the requirements above supersede conflicting prescriptions. Existing discussion is preserved.
Original issue: README Basic Usage promises deterministic output from a non-deterministic config
The README Basic Usage example (README.md:137-197) sends 5 items through a config of {MinItems: 2, MaxItems: 5, MinTime: 10ms, MaxTime: 100ms} and claims:
Expected output: 2 4 6 8 10
With MinItems: 2 the 5 items can split into multiple batches, and batches are processed in separate goroutines — so both the order and the grouping of the printed lines are non-deterministic. This is the same class of problem #69 fixed in example_test.go (which now uses a single-item, single-batch config); the README front-door example was left behind.
Fix: either use a config that guarantees one batch (e.g. MinItems: 5, MaxItems: 5) or soften the claim to "Output (order may vary)". Land together with the #84 config-semantics doc fix if convenient.
Found in the 2026-07-10 full-repo review.
Current outcome
Keep the first example honest about grouping and ordering when batches can complete concurrently.
Replanned on 2026-09-06 against GoBatch master
63ef757and ShitQuant's recorder, enrichment, paper/replay, and flow workloads. This is an implementation target, not a claim that the behavior already exists.Required behavior
Verification and completion
Run the example with a controlled finite input and verify its stated guarantees. If order may vary, assert values/counts rather than an unsupported exact sequence.
Follow the repository's formatting, race-test, vet/lint, package documentation, example and changelog requirements for the changed surface. Report the actual supported behavior and migration; do not treat a passing coverage percentage as proof of these outcomes.
Scope and relationships
Can be fixed independently and coordinated with #84; no prerequisite on unrelated PR merges.
Design history
The earlier report/prototype remains below for provenance; the requirements above supersede conflicting prescriptions. Existing discussion is preserved.
Original issue: README Basic Usage promises deterministic output from a non-deterministic config
The README Basic Usage example (
README.md:137-197) sends 5 items through a config of{MinItems: 2, MaxItems: 5, MinTime: 10ms, MaxTime: 100ms}and claims:With
MinItems: 2the 5 items can split into multiple batches, and batches are processed in separate goroutines — so both the order and the grouping of the printed lines are non-deterministic. This is the same class of problem #69 fixed inexample_test.go(which now uses a single-item, single-batch config); the README front-door example was left behind.Fix: either use a config that guarantees one batch (e.g.
MinItems: 5, MaxItems: 5) or soften the claim to "Output (order may vary)". Land together with the #84 config-semantics doc fix if convenient.Found in the 2026-07-10 full-repo review.