gsadmin/sencho
1
0
Fork 0
mirror of https://github.com/Studio-Saelix/sencho.git synced 2026-08-09 10:21:03 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix(fleet): make local self-update flow reliable end-to-end (#472)

Browse Source 
The "Updating Sencho..." overlay used to dismiss prematurely while the
image pull was still running, after which the local node card would get
stuck in "updating" and eventually surface a generic "Timed Out" error
while the container remained on the old version.

Three root causes are addressed:

1. The image pull was synchronous (`execFileSync`), which blocked the
   Node event loop. The overlay's health probe saw the server come back
   the moment the pull finished and reloaded the page, even though the
   container had not restarted yet. The pull is now async via
   `promisify(execFile)`, so /api/health and /api/fleet/update-status
   keep serving throughout.

2. The overlay reloaded on the first 200 from /api/health regardless of
   whether the underlying process had actually restarted. /api/health
   now exposes the gateway boot timestamp, and the overlay captures it
   pre-update and only reloads when it observes a different value. A
   wasOffline-then-online fallback handles the case where the pre-update
   fetch failed.

3. Helper container spawn errors from `docker run` were silently
   discarded, so a failed compose recreate never surfaced anywhere.
   Errors are now captured into `lastUpdateError` via the execFile
   callback and surfaced through the existing /api/fleet/update-status
   error path.

A 3-minute early-fail heuristic on the local node block surfaces a clear
failure message when the helper fails silently, instead of waiting the
full 5-minute timeout for an unknown failure.
This commit is contained in:
Anso
2026-04-10 12:00:44 -04:00
committed by GitHub
parent c09673d8bb
commit 3d69746eee
5 changed files with 103 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/features/remote-updates.mdx
+3 -3
View File
@@ -74,10 +74,10 @@ When you update the local (gateway) node:
1. A confirmation dialog appears explaining that the dashboard will briefly disconnect.
2. After confirming, the server pulls the latest image and restarts.
3. A reconnecting overlay appears and polls the server every few seconds.
4. The page automatically reloads when the server comes back.
3. A reconnecting overlay appears and polls the server every few seconds. It stays visible for the entire pull and restart cycle, even if the API briefly responds in between, so the page does not reload until the new container has actually booted.
4. Once the new container reports a fresh boot timestamp, the page automatically reloads with the new version.
If the server does not return within 5 minutes, a timeout message appears with a manual reload option.
If the new container does not come up within 5 minutes, a timeout message appears with a manual reload option. If the gateway can detect that the update did not complete (for example, the image pull failed or the restart helper container could not spawn), the local node card surfaces a "Failed" badge with the underlying error within about 3 minutes instead of waiting for the full timeout.
## What happens during an update