doProcessing snapshots the config once per batch (batch/batch.go:407):
config := fixConfig(b.config.Get())
batch := b.waitForItems(ctx, config)
waitForItems then runs to completion against that snapshot. With {MinItems: 100, MaxTime: 0} and an idle source, the wait can block indefinitely — and a later DynamicConfig.UpdateBatchSize(1, 0) is never observed, because Config.Get() is not re-polled inside the wait. The pipeline stalls forever, which defeats the runtime-adjustability use case the DynamicConfig godoc advertises.
Suggested fix: re-poll Config.Get() inside waitForItems (e.g. on each timer/receive iteration) so updates can unstick an in-flight wait. Alternatively, document batch-boundary granularity — but that leaves the stalled-pipeline footgun in place, so the code fix is preferred.
Related: #86 covers the missing test, #84 covers the doc gap; neither covers this behavior bug.
Found in the 2026-07-10 full-repo review.
doProcessingsnapshots the config once per batch (batch/batch.go:407):waitForItemsthen runs to completion against that snapshot. With{MinItems: 100, MaxTime: 0}and an idle source, the wait can block indefinitely — and a laterDynamicConfig.UpdateBatchSize(1, 0)is never observed, becauseConfig.Get()is not re-polled inside the wait. The pipeline stalls forever, which defeats the runtime-adjustability use case theDynamicConfiggodoc advertises.Suggested fix: re-poll
Config.Get()insidewaitForItems(e.g. on each timer/receive iteration) so updates can unstick an in-flight wait. Alternatively, document batch-boundary granularity — but that leaves the stalled-pipeline footgun in place, so the code fix is preferred.Related: #86 covers the missing test, #84 covers the doc gap; neither covers this behavior bug.
Found in the 2026-07-10 full-repo review.