A deployed update is invisible until you happen to refresh #10

New issue

Open

opened 2026-08-26 12:24:03 +09:00 by floot · 0 comments

floot commented

2026-08-26 12:24:03 +09:00

Owner

That happened during this session more than once, including a report that a
fix "looked the same" when the tab had simply not picked it up.

Nothing in packages/chat tracks a build identity today — no service worker,
no version endpoint, no reload prompt.

Proposal

Give the served bundle an identity and let the running tab notice when it
changes:

Serve the running revision (the deploy unit already knows it — it is the
pinned rev, and current symlinks to releases/<rev>).
The app compares its own build identity against the served one, on an
interval and on regaining visibility, and shows an unobtrusive "a new
version is available — reload" affordance when they differ.
Reloading is the USER's choice, not automatic: a reload mid-turn would
throw away what is on screen, and a voice session in particular should not
be interrupted by the page reloading under it.

Notes

A daemon restart already breaks the CapTP connection, so the app has a
natural moment to check: whatever handles reconnection is the obvious place
to ask "is this the same build I started with?".
Worth deciding whether a mismatch should be shown differently when the tab
is idle versus mid-turn. Idle is a safe moment to nudge; mid-turn is not.

Applying a release restarts the daemon and swaps the served bundle, but an open tab keeps running the old one and says nothing about it. You only find out by refreshing on a hunch — and the failure mode is quiet in the worst way: you look at a change you just deployed, see the old behaviour, and conclude the change did not work. That happened during this session more than once, including a report that a fix "looked the same" when the tab had simply not picked it up. Nothing in `packages/chat` tracks a build identity today — no service worker, no version endpoint, no reload prompt. ## Proposal Give the served bundle an identity and let the running tab notice when it changes: 1. Serve the running revision (the deploy unit already knows it — it is the pinned rev, and `current` symlinks to `releases/<rev>`). 2. The app compares its own build identity against the served one, on an interval and on regaining visibility, and shows an unobtrusive "a new version is available — reload" affordance when they differ. 3. Reloading is the USER's choice, not automatic: a reload mid-turn would throw away what is on screen, and a voice session in particular should not be interrupted by the page reloading under it. ## Notes - A daemon restart already breaks the CapTP connection, so the app has a natural moment to check: whatever handles reconnection is the obvious place to ask "is this the same build I started with?". - Worth deciding whether a mismatch should be shown differently when the tab is idle versus mid-turn. Idle is a safe moment to nudge; mid-turn is not.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

floot/endo#10

No description provided.

Rows
Columns