diff options
| author | Christophe Besson <cbesson@gmail.com> | 2026-10-07 22:17:27 +0200 |
|---|---|---|
| committer | Christophe Besson <cbesson@gmail.com> | 2026-10-07 22:22:51 +0200 |
| commit | b06338abf7a5be58151828acb801286c05a3d62a (patch) | |
| tree | 32ba77301f9f8f798f6aba953ce02fd9b5a57235 /packages/meshbay-hub/tests/harness/group_tab_probe.py | |
| parent | e0dde3466fcb06570cc41b1c379707b2807040ad (diff) | |
| download | meshbay-b06338abf7a5be58151828acb801286c05a3d62a.tar.gz | |
fix(client): stop the node at Quit in "only while open", whoever started it
Switching from "at sign-in" to "only while MeshBay is open" left the node the
sign-in launcher had started running after Quit: only a node this process had
started was stopped. In that mode the app owns the node, so Quit stops the
one that is there.
The start with the app and the sign-in's own start (ensureNode) also both ran
`autostart start` at launch -- three meshbay-node.exe were seen racing for the
port. The sign-in's start and node:start now wait for the launch's.
The end-to-end test covers the mode: Quit leaves no node, opening the app
starts one. It launches the app with the environment it was imported with:
the suite's conftest points HOME, USERPROFILE, LOCALAPPDATA and APPDATA at a
throwaway directory per test, and the app started under that crashed at once
(0x80000003), which first looked like a crash of the app itself.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Diffstat (limited to 'packages/meshbay-hub/tests/harness/group_tab_probe.py')
0 files changed, 0 insertions, 0 deletions