Repository navigation
fix(inbox): a closing tab no longer counts itself again after pagehide (notify_reach e2e) - #2250
Merged
Merged
Conversation
…ents e2e The notify_reach test (inbox-shared-events.spec.ts) fails on CI with windows 2 after its 17 s hold, and does not reproduce on macOS or in a Linux container. This commit only collects evidence from GitHub's runner: the Inbox traces each window change (PLANNOTATOR_E2E_WINDOWS_TRACE, set by the shared-events world only), the test records each tab's requests and the count over time into the proof artifact, and the workflow runs the file 8 times before the full proof. It is reverted before review.
A closing tab still runs for a moment after pagehide. When it led, the next leader's announcement and its relayed hello reached it there, and each sent a window report (served_by the next leader). That report clears `gone`; landing after the other tab's lock-watch `gone`, it left a closed tab counted for as long as the next leader's stream stayed open. This is the notify_reach e2e "Expected 1, Received 2" after the leader closes. Now the tab reports nothing from pagehide until a pageshow brings it back. Co-Authored-By: Claude <noreply@anthropic.com>
…hared-events e2e" This reverts commit 727d41f.
Co-Authored-By: Claude <noreply@anthropic.com>
backnotprop
marked this pull request as ready for review
October 27, 2026 20:01
…r changes Guards the pageshow line that clears the post-pagehide silence; the header comment now names that silence. Co-Authored-By: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
inbox-shared-events.spec.ts"notify_reach follows the tabs" failed on #2242 and #2219 withExpected: 1, Received: 2after the leader closes. It is a real race in the product, not a test timing problem. It is present since the shared stream landed (612ef88) and is not a regression from #2234.Cause. At
pagehidea tab sendsgoneand steps down, but its scripts still run for a moment. When the closing tab led, the next leader's announcement and its relayedhelloreached it there. Each sentPOST /api/inbox/windowwithserved_byset to the next leader, which clearsgoneon the server. If that late report lands after the next leader's lock-watchgone, the closed tab stays counted for as long as the new leader's stream is open.A server trace on CI (diagnostic commit, since reverted) shows the window:
leavefrom the old leader, thenreportfrom the same window 5 ms later, thenleaveagain from the new leader 37 ms later. Here the order was benign. In the failed runs it was reversed.Fix.
sharedEvents.ts: a tab that saidgoneat pagehide reports nothing (onConnectfrom a new leader or a relayedhello) until apageshowbrings it back from the back/forward cache. The e2e test is unchanged.Evidence.
bun test packages/inbox/: 469 pass.--repeat-each 20on the compiled binary: 20/20 pass. The whole shared-events file: 12 pass, 2 skipped as designed.