fix(desktop): l'app démarre après une mise à jour, et parle quand elle ne peut pas
Installer une nouvelle version remplace les fichiers sur disque mais ne touche
pas le process en cours : l'ancienne instance gardait le port 7317, la version
fraîchement installée mourait sur EADDRINUSE avant son handshake, et le shell se
contentait d'un console.error suivi d'un app.quit(). Depuis le lanceur, cliquer
l'icône ne produisait donc rien du tout.
- Tout échec de démarrage ouvre un dialogue Retry / Show log / Quit
(start-failure.ts, texte pur et testé) et la sortie du daemon est conservée
dans <userData>/logs/daemon.log. Une mort du daemon APRÈS le handshake propose
de le relancer, au lieu de laisser une fenêtre morte à l'écran.
- Le port est diagnostiqué avant le spawn (port-guard.ts, empreinte
{pid, ownerPid, port}) : un daemon orphelin, dont l'Electron est mort, est
repris (SIGTERM puis SIGKILL, en attendant un bind réellement possible) ;
une instance vivante ou un tiers (service, npx) est annoncé avec l'action qui
débloque, et jamais tué. La reprise exige deux preuves, l'empreinte orpheline
ET l'identité du process (ps -ww), car un pidfile périmé peut désigner un pid
recyclé entre-temps par un programme quelconque.
- Une mise à jour installée à chaud est signalée avec « Restart now »
(upgrade-watch.ts), qui arrête le daemon avant app.relaunch() ; sans quoi le
lock d'instance unique renvoyait silencieusement sur la fenêtre de l'ancienne
version, et on croyait avoir migré.
- ARBORETUM_DESKTOP_PORT pour cohabiter avec un Arboretum qui occupe 7317 en
permanence (service installé, ou daemon lancé en terminal).
24 tests dans packages/desktop/test, et quatre scénarios rejoués en dev sous
xvfb-run avec profil isolé : port tenu par un tiers, orphelin repris puis SPA
servie, instance vivante laissée intacte, pid recyclé épargné.
This commit is contained in:
@@ -4,6 +4,26 @@ Notable changes to the Arboretum desktop app (`packages/desktop`). The daemon an
|
||||
extension keep their own changelogs in `packages/server/CHANGELOG.md` and
|
||||
`packages/vscode/CHANGELOG.md`.
|
||||
|
||||
## Unreleased
|
||||
|
||||
- **The app could refuse to start after an update, silently.** Installing a new version replaces the
|
||||
files on disk but leaves the running app alone: its daemon kept port 7317, so the version you just
|
||||
installed hit `EADDRINUSE`, its daemon died before the handshake, and the shell logged the failure to a
|
||||
console nobody sees and quit. Clicking the launcher appeared to do nothing at all. Three fixes:
|
||||
- **Every start-up failure now opens a dialog** with *Retry / Show log / Quit* instead of vanishing,
|
||||
and the daemon's output is kept in `<userData>/logs/daemon.log`. A daemon that dies *after* start-up
|
||||
is reported too, with an offer to restart it, instead of leaving a dead window on screen.
|
||||
- **A busy port is diagnosed, not just fatal** (`src/main/port-guard.ts`). The daemon we spawn is
|
||||
recorded in `<userData>/daemon/daemon.json`, so an *orphaned* daemon (its Electron gone after a
|
||||
crash, a `kill -9` or an upgrade) is reclaimed - SIGTERM then SIGKILL, waiting for the port to be
|
||||
effectively free - while a live sibling instance or third-party server is reported with the action
|
||||
that unblocks it, and never killed.
|
||||
- **An update installed while the app runs is announced** (`src/main/upgrade-watch.ts`). Until now the
|
||||
single-instance lock quietly routed you back to the old version's window; the shell now notices its
|
||||
own binary changed on disk and offers *Restart now*, which stops the daemon before relaunching.
|
||||
- **`ARBORETUM_DESKTOP_PORT`** picks another port, for machines where a service or terminal daemon owns
|
||||
7317 permanently.
|
||||
|
||||
## 0.2.3
|
||||
|
||||
Ships the daemon 3.6.0. Files open again (the editor area could stay blank), and uncommitted work
|
||||
|
||||
Reference in New Issue
Block a user