Flake
TestExternalNATS_ResetOrphaned (internal/mq/external_test.go) failed once in a local make ci (integration backends phase) on a branch that changes no Go code under internal/; the same code passed make ci several times the same day. A re-run is in progress.
What failed (measured)
The first check, right after the two publishes:
external_test.go:879:
Error: Expected error with "unit held by a consumer" in chain but got nil.
Messages: a live holder's rows are its own
So b.ResetOrphaned(unit) returned no error while broker a was supposed to be the unit's live holder, before a is closed.
What the test assumes
The test starts a's unit consumer (unitConsumer(t, a, unit, &hold)), publishes two rows, and immediately asks b to reset the unit, expecting ErrUnitHeld. ResetOrphaned leaves a unit alone while a client holds the pin or was active on it within the quiet window. Nothing in the test waits for a to hold the pin, or to have received a row, before the first ResetOrphaned call, so under load the call can run before the server has pinned a or recorded any delivery to it. That ordering is inferred from the test code, not shown: the failing run's server state was not captured.
Part of #740.
Flake
TestExternalNATS_ResetOrphaned(internal/mq/external_test.go) failed once in a localmake ci(integration backends phase) on a branch that changes no Go code underinternal/; the same code passedmake ciseveral times the same day. A re-run is in progress.What failed (measured)
The first check, right after the two publishes:
So
b.ResetOrphaned(unit)returned no error while brokerawas supposed to be the unit's live holder, beforeais closed.What the test assumes
The test starts
a's unit consumer (unitConsumer(t, a, unit, &hold)), publishes two rows, and immediately asksbto reset the unit, expectingErrUnitHeld.ResetOrphanedleaves a unit alone while a client holds the pin or was active on it within the quiet window. Nothing in the test waits forato hold the pin, or to have received a row, before the firstResetOrphanedcall, so under load the call can run before the server has pinnedaor recorded any delivery to it. That ordering is inferred from the test code, not shown: the failing run's server state was not captured.Part of #740.