diff options
| author | Christophe Besson <cbesson@gmail.com> | 2026-09-04 16:24:08 +0200 |
|---|---|---|
| committer | Christophe Besson <cbesson@gmail.com> | 2026-09-04 16:24:08 +0200 |
| commit | 046d847c1b7ba9fcc8e0f3be6e4ff13dac016479 (patch) | |
| tree | 15abc20457e68d662ae2a5918916d89859ebce04 /packaging/win/README.md | |
| parent | a4aabd1d33770d6199a8cb7bc87f639668617bc9 (diff) | |
| download | meshbay-046d847c1b7ba9fcc8e0f3be6e4ff13dac016479.tar.gz | |
fix(client): a failed spawn() of the node no longer crashes the app
spawnNodeDetached() and the Linux dev-mode fallback in node:start called
spawn() with no 'error' listener. A spawn failure -- bad path, a stale
PATH entry, antivirus interference -- is delivered on that event
asynchronously; with nothing listening, Node rethrows it as an uncaught
exception and takes the whole Electron main process down with it, instead
of the caller's own waitForNode() timeout turning "never came up" into a
clean message.
Hit directly: ENOENT spawning a stale dev-venv meshbay-node.exe (not the
installed one -- where.exe correctly resolves to the bundled exe now).
Whatever the trigger, a daemon that fails to start must never be able to
take the renderer down with it.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Diffstat (limited to 'packaging/win/README.md')
0 files changed, 0 insertions, 0 deletions