You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
streaming-remount background-restore test is flaky on macOS #3061
apps/desktop/e2e/streaming-remount.spec.ts:67 ("returning to a live conversation settles output accumulated while away") fails roughly one run in six on macOS, and only when the whole file runs — the test passes consistently on its own.
The failing assertion is that no intermediate paint shows partially accumulated background output:
The observer watches document.body with subtree: true and samples .maka-bubble-streaming's textContent on every mutation, so its sampling rate depends on how much unrelated DOM churns during the restore. That makes it sensitive to changes elsewhere in the shell, which is a fragile way to assert "no intermediate paint".
Measured before and after #3033's row rebuild: about 1 failure in 7 and 1 in 6 respectively, so the rate is not obviously changed by that work. CI (Linux) has not reproduced it.
Either the intermediate paint is real and rare — in which case the test is finding a genuine bug and should be made deterministic enough to prove it — or the observation method is too coarse. Worth resolving before it gets muted.
Additional data point, measured today on macOS 15 (Darwin 25.5.0) while working on #3033.
The failure rate on this machine is currently 3/3 when the file runs, not the ~1-in-6 recorded above. Measured against the branch state with no changes in the working tree, so it is not caused by the rail work; CI's e2e job passed on the same commit, so it stays machine- and load-dependent.
The passing/failing split is unchanged: --grep "accumulated while away" passes on its own, every time. Only the whole-file run fails, which is consistent with the diagnosis above — the observer samples on every document.body mutation, so what it catches depends on unrelated churn, and a warmer or busier machine changes that.
Activity
Astro-Han commentedon Aug 15, 2026
Additional data point, measured today on macOS 15 (Darwin 25.5.0) while working on #3033.
The failure rate on this machine is currently 3/3 when the file runs, not the ~1-in-6 recorded above. Measured against the branch state with no changes in the working tree, so it is not caused by the rail work; CI's
e2ejob passed on the same commit, so it stays machine- and load-dependent.The passing/failing split is unchanged:
--grep "accumulated while away"passes on its own, every time. Only the whole-file run fails, which is consistent with the diagnosis above — the observer samples on everydocument.bodymutation, so what it catches depends on unrelated churn, and a warmer or busier machine changes that.Generated-by: Claude Code
test(desktop): sample remount restore on painted frames (apache#3101)