mirror of
https://github.com/PerpetualSoftware/pad.git
synced 2026-09-23 02:53:31 +00:00
xarmian
63c45bc651
TestConcurrentPublishesDeliverInIDOrder published 320 events while a goroutine drained concurrently, then guarded against vacuity with "at least half must arrive". That guard is a bet on runner speed. The bus DELIBERATELY drops for a subscriber that cannot keep up, so the arrival count is a continuous function of how much CPU the reader gets: across four CI instances on three PRs it reported 64, 65, 144 and 150 of 320, and 64 is exactly the subscriber channel depth -- one buffer-full and nothing after it. Any "require N of 320" line is a bet on the same variable, which is why this is not a threshold change. The sample is made untruncatable instead of large. No reader runs during the publishes and fewer events are published than the channel is deep, so a drop cannot occur; the vacuity guard becomes count == total, an equality rather than a threshold. Nothing in the assertion path waits on a goroutine being scheduled, so the result no longer depends on load at all. Detection power then comes from repeating the round, which is what the bounded channel could not provide. Measured against the mutation the test exists to catch (release replayMu after the append so fan-out runs outside it): the version replaced here caught it 9 times in 30 runs; this one caught it 25 times in 25, at about 10ms against the old fixed 0.5s. subscriberChanDepth is named rather than inlined so the test states its no-drop premise in terms of the real depth. A test that hardcoded 64 next to it would silently stop proving what it claims the day the depth changed.