Flaky test: lifetime-pipe watcher may not observe Close on Linux
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 152
- Forks
- 16
- Avg merge
- 14h 48m
- Merged PRs (30d)
- 536
Description
Bug description
The root-b race shard intermittently fails in TestSDKServerEnablers_Scenario8_LifetimePipeIsQuietOnCleanShutdown after waiting 10 seconds for the lifetime-pipe watcher to observe p.Close().
Observed failures:
- https://github.com/stacklok/mecatl/actions/runs/35215461411/job/105182991940
- https://github.com/stacklok/mecatl/actions/runs/35225076659/job/105214547427
Both fail with:
--- FAIL: TestSDKServerEnablers_Scenario8_LifetimePipeIsQuietOnCleanShutdown (10.00s)
daemonhosting_test.go:959: the watcher did not observe its own Close within 10s
No race-detector report is present.
Steps to reproduce
Run the root-b race shard repeatedly on Linux:
task test:race-root-b
The scheduling-sensitive sequence is:
openLifetimePipewraps a blocking inherited pipe descriptor withos.NewFileand startswatch.watchmay enter a blockingReadwhile the writer remains open.- The test calls
p.Close()and waits forp.Closed().
On Linux, closing the descriptor from another goroutine does not guarantee that an already-blocked read wakes. If Close wins before Read, the test passes; if Read wins, it can remain blocked until the writer closes.
Expected behavior
The test should verify that clean shutdown does not emit lifetime pipe read failed without requiring an unsupported join guarantee from lifetimePipe.Close.
Actual behavior
The test asserts that Close wakes and joins the watcher within 10 seconds. This contradicts both the implementation comment and ADR 0027 List 1 row 66, which explicitly state that Close does not join the watcher and that it exits when the parent endpoint reaches EOF.
Environment
- OS/version: GitHub-hosted Ubuntu 24.04 runners
- Go: 1.27.x with
-race - Deployment shape:
cmd/mecatedunit test in the root-b race shard
Suggested fix
Align the fixture with the documented lifecycle: call p.Close(), close the writer to release any in-flight Linux read, then wait for p.Closed() before checking the captured logs. Increasing the timeout alone will retain the race.
Tracked alongside #815 because both surfaced in the race shards, but the causes and fixes are independent.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with daemonhosting_test.go and TestSDKServerEnablers_Scenario8_LifetimePipeIsQuietOnCleanShutdown. Run task test:race-root-b repeatedly on Linux, then inspect the lifetime-pipe fixture and its Close/Closed sequence. Align the test with the documented lifecycle by releasing the writer before waiting for Closed, and verify clean shutdown does not log lifetime pipe read failed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- testing-qa
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 84/100