Repository navigation
test: TestShutdownEndsOwedOpsBeforeClosing failed once in CI (Unit steps), passed on re-run #1081
Description
TestShutdownEndsOwedOpsBeforeClosing failed once in CI ("Unit steps" job, PR #1058, head 9f8543e, first attempt) and passed on the re-run of the same commit. The PR changes the io_uring driver Write path only; this is an HTTP descriptor-lifetime test that does not call driver Write, so I think it is an existing timing assumption. It passed 60 of 60 locally on both the branch and main (arm64, container, -race).
Needs: find the failing attempt's log (the PR's first Unit steps run), reproduce with -race -count=N under CPU pressure, then either make the wait condition observable instead of time-based or fix the engine if the owed-ops ordering really breaks.
Activity
FumingPower3925 commentedon Oct 19, 2026
Second occurrence: PR #1080 (head after update-branch), run https://github.com/goceleris/celeris/actions/runs/39318141976, job 'Unit steps', step 'internal/engine/iouring — race tests at the runner memlock', same test, 0.02 s. Both failures are after #1079 merged; investigating whether it is a regression of #1079 rather than a pre-existing flake.
iouring: the serverFDFor and #1081 test comments say the stray CI met…
iouring: serverFDFor matches both ends of the dialed connection (Refs #…
iouring: serverFDFor matches both ends of the dialed connection (Refs #…
FumingPower3925 commentedon Oct 25, 2026
Closing as fixed by #1083 (merged 2026-10-19). Cause: the
serverFDFortest helper picked the wrong descriptor (a leftover socket instead of the server side of the dialed conn). #1083 carries a deterministic test,TestServerFDForIsTheServerSideOfTheDialedConn1081.Evidence: I ran that test against the helper as it was before #1083: it fails 5 of 5; with #1083's helper it passes 5 of 5. CI: 0 failures of this test in about 211 job executions since #1083 (a statistical bound alone would not prove the fix: against the failure rate since #1056 it is Fisher p about 0.13, so the deterministic test is the proof). The open question "regression of #1079?" has no supporting evidence: #1079's worker/engine hunks only touch multishot, parse-address and notice code, and a socket census at the start of the test gave identical results on the trees before and after #1079; the two failures fell in the 14 Unit jobs between #1079 and #1083, a clustering with p about 0.013 after the fact, which is weak.