Repository navigation
macOS smoke: TestScanSSEDataWithContextContentResetsOnData hit the idle timeout once #1140
Description
Version / branch / commit
main @ 846d30f5. The PR that hit it, #1139, is 846d30f5 plus two commits that only touch internal/cli/sandbox_test.go.
OS and environment
GitHub Actions macos-latest, job Smoke (macos-latest), step "Test (Fast Non-Race)".
Steps to reproduce
Not reproduced locally (I only have Linux). It failed once in CI:
- Run: https://github.com/Twigpine/zero/actions/runs/38625106440
- Job: https://github.com/Twigpine/zero/actions/runs/38625106440/job/116062145361
Expected behavior
TestScanSSEDataWithContextContentResetsOnData passes: a stream that keeps producing a data line every 30 ms is never aborted by the 100 ms idle timeout.
Actual behavior
--- FAIL: TestScanSSEDataWithContextContentResetsOnData (0.26s)
providerio_test.go:312: err = idle timeout (upstream stopped sending data), want nil (data kept the stream alive)
FAIL github.com/Gitlawb/zero/internal/providers/providerio 7.595s
Why this looks like a flake rather than a regression in that PR
- test(cli): pin sandbox policy golden temp roots #1139 does not touch
internal/providers; the package is identical tomainat846d30f5. Smoke (macos-latest)passed onmainfor846d30f5: https://github.com/Twigpine/zero/actions/runs/38581230002- It is the only failure in that log.
What I did not establish
This is a single occurrence. My guess, which I have not verified, is the margin: the test writes every 30 ms against a 100 ms idle timeout, so a scheduling stall of about 70 ms on a busy shared runner would be enough. I have no fix to propose. If it helps, I am happy to look at whether a wider idle window or an injected clock fits how the rest of the package is tested.
Thank you for looking at it.
Activity
Vasanthdev2004 commentedon Oct 16, 2026
Your read of the margin is right. The content window is
ContentStallTimeout(idle), which is 1.2× the idle timeout, so the test runs 300 ms of writes against a 120 ms content window and a 100 ms idle timeout. That leaves 70 ms of slack on every 30 ms gap, and one scheduling stall of that size on a shared macOS runner is enough.The test needs two things to stay true: each gap well under the idle timeout, and the whole run longer than the content window, so the content watchdog is actually reset rather than never reached. Scaling the idle timeout up keeps both. For example, 500 ms idle gives a 600 ms content window, and 25 writes every 30 ms run for about 750 ms. That's 470 ms of slack per gap, and the test still finishes in under a second. The
n != 10check moves with the write count.Marking this approved. Go ahead if you'd like to take it.