Skip to content

test: the dashboard's link brings the open window, a move, and windows quit as a person quits - #38

Merged
aledbf merged 1 commit into
mainfrom
test/lane-reuse-moved
Nov 14, 2026
Merged

aledbf merged 1 commit into
mainfrom
test/lane-reuse-moved

Conversation

@aledbf

@aledbf aledbf commented Nov 14, 2026

Copy link
Copy Markdown
Member

Follow-up to #37, adding the last two items from #24.

reuse (window reuse, from spin#1119)

With a window connected to spin+e2e-running, the lane hands the running VS Code the dashboard's link for that workspace, by its id, the way the OS hands it.

  • Spinbox's spin code <id> answers the same folder as the open window.
  • VS Code brings that existing window (doOpenFilesInExistingWindow), even though Spinbox asks openFolder for a new one.
  • No second window opens.

No product change was needed. The lane now holds this behavior. VS Code's once-only "Allow 'Spinbox' to open this URI?" prompt is answered in the lane's settings.

moved

spin workspace move runs under a connected window. The window comes back in 12 s with the same shell, but on the same host: the reconnect's spin code --start resumes the workspace while the move has it suspended, and the move aborts. That is spin#1225. The case runs only with CASES=moved, after task e2e:hosts:up, and it fails until spin#1225 is fixed.

Windows quit as a person quits

Each case now quits VS Code through the probe (workbench.action.quit), and only kills it if it doesn't quit.

When VS Code was killed, the window never told the workspace's server it had gone, so the server kept that window's extension host for the reconnection grace period (3 h). That cost about 150–400 MB per window. After roughly 8 windows, a 2 GB workspace could no longer start processes: spawn EAGAIN, ssh sessions closed right after login, and spin exec failing. With the quit, memory holds at the server's own level after each window.

The same leftover happens to a person after a crash or a dropped network. I'm noting it here, not fixing it.

Verified

Against spin's e2e stack (f15122137), VS Code 1.146.0, Spinbox Remote with open-remote-ssh#17: test:spin-remote passed 19/19 and test:remote-ssh passed 14/14. task ci is green.

Part of #24.

🤖 Generated with Claude Code

…s quit as a person quits

reuse: with a window connected to spin+e2e-running, the dashboard's link for it, by its id,
is handed to the running VS Code as the OS hands it. Spinbox's spin code answers the same
folder, and VS Code brings that window (doOpenFilesInExistingWindow) though Spinbox asks
openFolder for a new one: no second window, which is what spin#1119 asked of the extension.
The lane holds it. VS Code's once-asked 'Allow Spinbox to open this URI?' is answered in the
lane's settings, as the person who said yes to the dashboard's first link.

moved: spin workspace move under a connected window, given minutes. The window is back in
12 s with the same shell, but on the host it had: the reconnect's spin code --start resumes
the workspace while the move has it suspended, and the move aborts (spin#1225). Run only with
CASES=moved, after spin's task e2e:hosts:up.

Each case now quits VS Code through the probe (workbench.action.quit) and kills it only when
it does not quit. Killed, a window never told the workspace's server it went, and the server
kept its extension host for the reconnection's grace: about 150-400 MB a window, until a 2 GB
workspace could start no process (spawn EAGAIN, ssh sessions closed after login, spin exec
failing). Quit, memory holds at the server's own after each window.

Against spin's e2e stack (f15122137), VS Code 1.146.0, Spinbox Remote with open-remote-ssh#17:
test:spin-remote 19/19, test:remote-ssh 14/14.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@aledbf
aledbf merged commit 11bf9de into main Nov 14, 2026
3 checks passed
@aledbf
aledbf deleted the test/lane-reuse-moved branch November 14, 2026 06:47
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.

1 participant