| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
Found by the first Windows beta tester, then reproduced on a clean install.
After a service-mode install nothing set the node up for the account that
signed in: the boot task started a node that quit ("hub.username not set"),
and the sidebar showed Node / Create group only once the hub held a node key.
The only way to the wizard that provisions was the home page's welcome card,
which an account already in a group never sees. The way out was
`meshbay-node init` and the key pasted on the profile page -- which is also
what PACKAGING-GUIDE.md told people to do.
- main.js `node:ensure`, called by app.js at sign-in: provisions, starts and
links the node this build ships (Windows, bundled node only). A node set up
for another account, or an account linked to another node, is left alone.
node:start waits for it, so the two never race.
- The sidebar shows the Node section when a node exists on this machine.
- The Node page's status is the node's: its control API and the process
list, not the service task's state (a node started from a terminal ran
while the page said Stopped). Stop says Stopped only once no
meshbay-node.exe is left, and stays offered for a process that answers
nothing.
- CLI stop kills the pid that answered when a graceful stop does not finish,
and fails with the reason when a node process is still there.
- The daemon ends its process 3s after _shutdown(): Python's exit waited for a
busy indexer thread, with the control API already closed. Armed by main()
only, never by a daemon run inside a test.
- node.toml is read as utf-8-sig (PowerShell 5.1 writes a BOM), and a config
that cannot be read is logged instead of dying silently in service mode.
- "Pair this browser" queues the code for the next group of this node to
open instead of saying "Paired successfully"; no banner before a group.
- test_e2e_windows_app.py (opt-in, MESHBAY_WIN_E2E=1) drives the installed
app against a throwaway hub: fresh account to linked node, Stop, Start,
Restart, checked against the real processes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|