test: make Example_* output deterministic

[MasterOfBinary]

Summary

Several Example_* tests printed from inside Process and relied on a hardcoded // Output: block that assumed batches print in order. The engine dispatches one goroutine per batch with no cross-batch happens-before, so ordering was held only by time.Sleep in the sources — latent CI flakiness that could fail the build non-deterministically on a loaded runner.

Fix

Each affected example made deterministic with the least-invasive technique:

• Single-batch config (MinItems == MaxItems >= N) so there is exactly one printing goroutine — Example, Example_simpleProcessor, Example_processorChain, Example_errorHandling.
• Collect-then-print after <-b.Done() for Example_dynamicConfig (which inherently demonstrates runtime resizing); asserts invariants rather than interleaved order.
• Example_customConfig left unchanged — every batch prints an identical line, so it is already order-independent.

No examples were downgraded to non-verified (// no output) form.

Testing

go test -run Example -count=20 ./batch/ and the same at GOMAXPROCS=1 pass on every run (also verified under CPU-burner load). Full go test -race ./... green.

Backwards compatibility

Test-only; no library code touched.

---

Part of a 5-PR set from a full-repo review; file-disjoint and independently mergeable in any order.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.76%. Comparing base (ba2a756) to head (4785ea8).
⚠️ Report is 2 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master      #69      +/-   ##
==========================================
+ Coverage   96.73%   96.76%   +0.02%     
==========================================
  Files          12       12              
  Lines         368      371       +3     
==========================================
+ Hits          356      359       +3     
  Misses          9        9              
  Partials        3        3              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[gemini-code-assist]

Code Review

This pull request refactors several example tests in the batch package to ensure deterministic and stable outputs. This is achieved by removing time.Sleep calls, eliminating non-deterministic console prints from concurrent goroutines, and configuring the batchers to process all items in a single batch. The review feedback is highly constructive, suggesting a minor wording improvement in batch/example_error_handling_test.go to clarify that the batch is flushed due to EOF rather than reaching the MaxItems cap, which ensures technical accuracy.

[gemini-code-assist]

The comment states that MaxItems caps the batch, but since MaxItems is set to 15 and only 13 items are successfully emitted by the source (due to 2 source errors), the batch is actually flushed by EOF (end-of-input) rather than reaching the MaxItems cap. Clarifying this makes the explanation technically precise.

Suggested change

	// processor errors. MaxItems caps the batch; because two source reads are
	// reported as errors instead of items, the batch holds the 13 emitted
	// items and is flushed at end-of-input.
	// processor errors. Because two source reads are reported as errors instead
	// of items, the batch holds the 13 emitted items and is flushed at
	// end-of-input (EOF) rather than reaching the MaxItems cap.

[MasterOfBinary]

Good catch — applied in 4785ea8. The batch holds 13 items (two reads surface as source errors), so EOF is what flushes it, not the MaxItems cap.