Repository navigation
test: TestIssue1008_HandlerReturns503WhileSubpathIndexLoading races the background index build under load (-race flake) #227
Description
Activity
- added a commit that references this issue
on Oct 5, 2026 Fixed by #234 (merged as
3878d7ea).PacketStore.subpathBuildGate(nil in production) lets the test hold the background subpath index build until the 503 is asserted, then release it and assert 200. Under load the flake went from about 50/600 to 0/600. Readiness behaviour in production is unchanged, at the cost of one nil check perLoad().The sibling
TestIssue1008_PathHopIndexReadyFalseImmediatelyAfterLoadhas the same race class for the path-hop builder (1/900 under heavy load). That, and the unguardedclose(building)in the gate, are noted on #237.
Problem
Under CPU load,
TestIssue1008_HandlerReturns503WhileSubpathIndexLoadingincmd/serverfails occasionally withstatus = 200, want 503. This was found during the #214 review, which does not touch the store or the index code.Load(). That window races the background subpath index build on the test's 6-transmission fixture. When the build finishes first, the handler already returns 200.-racebinary:Fix direction
Make the not-ready window deterministic in the test. For example, hold the subpath index build with a test hook or gate until the 503 has been asserted, then release it and assert 200. Do not rely on the build being slower than the request.
Acceptance
go test -race -count=200 -run TestIssue1008_HandlerReturns503WhileSubpathIndexLoading ./cmd/server/passes under parallel CPU load (e.g. alongside anothergo test -racerun).