Skip to content

fix(plugin-browser): finish browser replay follow-ups - #460

Merged
shuv1337 merged 4 commits into
integration-v2from
cursor/browser-replay-followup-73a3
Oct 29, 2026
Merged

shuv1337 merged 4 commits into
integration-v2from
cursor/browser-replay-followup-73a3

Conversation

@shuv1337

@shuv1337 shuv1337 commented Oct 28, 2026 •

Copy link
Copy Markdown
Owner

Issue for this PR

Follow-up to #459.

Type of change

  • Bug fix
  • New feature
  • Refactor / code improvement
  • Documentation

What does this PR do?

Three leftovers from the review of #459, plus a fix for the retired-set race.

Waiting for a new desktop's first tab list races that attachment closing. If the desktop drops before it publishes tabs, the command fails with browser.disconnected instead of sitting for the full 2 second inventory grace.

A delete or move does not drop its session id before the woken command runs adopt. close only schedules that command. The wake carries a retired reason, which the command reads even if it runs after the handler returns, so an untaken command fails with "did not run" instead of parking for the reconnect grace or replaying onto a session that came back. The desktop-facing attach result stays closed. The id remains retired for one replayGrace (2 seconds). A later move or delete only extends that deadline, so overlapping events cannot clear each other. When the deadline passes, the id leaves the set.

A desktop that attaches again during that ban, and then drops, fails an in-flight command immediately. The ban is still in force, so the drop does not start another 2 second reconnect wait and does not replay the command.

Replay is still session-scoped. attach accepts sessionID, connectionID, and version: 4, and a supplied desktopID is discarded. The desktop mints a new connectionID with crypto.randomUUID() on every registration (packages/gui-extensions/src/browser/pane.ts), and nothing persists a desktop identity across reconnects. Pinning replay to the same desktop needs both sides:

  • Add a stable desktopID to the attach input and bump the browser RPC version.
  • Have the desktop create that id once per app install (not per registration) and send it on every attach.
  • On the server, store it on the attachment and replay an unretrieved command only when the next attachment has the same id. A different desktop replacing the session should fail the in-flight command instead of running it.
  • Cover same-id replay and different-id refusal in packages/plugin-browser, plus a desktop test that reconnects with the stored id.

That is not started here. A server-only optional field would not be sent by today's desktop, so it would not actually constrain replay.

How did you verify your code works?

bun test and bun typecheck in packages/plugin-browser (65 tests). The pre-push workspace typecheck passed.

The untaken delete and move tests were run against 4e38420944 and fail there (retired is already false). They pass on this branch: the command reports "did not run" with no clock advance, waiting is 0, a re-attach receives no command, and a drop of that re-attach also fails immediately.

Overlapping events are sequenced: move, 1 second, delete, 1 second and the session is still retired, 1 second more and it is not.

Screenshots / recordings

Not a UI change.

Checklist

  • I have tested my changes locally
  • I have not included unrelated changes in this PR
Open in Web Open in Cursor 

Forget a session after delete or move settles, and stop the tab-list wait
when that desktop closes. Attach still has no stable desktop id.
close only schedules the command it wakes, so deleting the retired id
before adopt runs lets that command park or replay. The wake carries a
retired reason, and the id stays banned for one reconnect grace.
Overlapping move and delete extend that deadline.
Leave the command untaken so delete and move reach adopt, and sequence a
move and a later delete across the reconnect grace.
Keep the retired-session replay ban and the v2.2.0 browser skill permission.
@shuv1337
shuv1337 merged commit cfbb96f into integration-v2 Oct 29, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants