mirror of
https://github.com/go-admin-team/go-admin.git
synced 2026-09-22 10:33:13 +00:00
zhangwenjian
047b23872c
The wait was one select over done and ctx.Done(). Both can be ready when it runs, select picks at random among ready cases, and so a queue that drained in the same instant the budget expired was reported as an overrun about half the times it landed there - often enough to be read as noise, and pointing at the wrong thing when it was not. core's own RunShutdown re-checks for this reason; this did not. The tie-break is now a function taking channels rather than a queue, which is what lets a test hand it a closed done and an expired ctx together. That state is the whole of the bug and cannot be arrived at reliably from the outside; over 1000 iterations the single-select version fails, and the second look does not. The test for giving up on the deadline read the call counter straight after shutdownQueue returned, while Shutdown runs on a goroutine nobody joins. It passed because the goroutine is scheduled promptly, not because anything ordered the two. The fake now signals that Shutdown has been entered and the test waits for it. Both raised by Copilot on #918. The first attempt at the tie-break test was wrong and is not what landed: it asserted that an immediately-returning Shutdown always counts as drained under an already-expired context, which is not true and should not be - if the goroutine has not run, nothing has drained. That test failed, correctly. What is being claimed is narrower: when both are ready, done wins.