Skip to content

feat(web): proactive reload affordance after web hot-swap (draft) - #294

Merged
patroza merged 2 commits into
fork/changesfrom
feat/web-version-signal
Aug 2, 2026
Merged

feat(web): proactive reload affordance after web hot-swap (draft)#294
patroza merged 2 commits into
fork/changesfrom
feat/web-version-signal

Conversation

@patroza

@patroza patroza commented Aug 2, 2026

Copy link
Copy Markdown
Owner

Item 4 of the independent-web-deploy work (builds on #293 + ops hot-swap). Proactively tells open clients a new web bundle is being served so they can reload, instead of only reloading passively on a failed chunk import.

What

  • contracts: webVersionChanged added to ServerLifecycleStreamEvent (payload = webVersion hash of index.html).
  • server: webVersionWatcher polls the served index.html hash every 10s and publishes on change; the current version seeds the lifecycle snapshot so a connecting client learns the version it's running. serverLifecycleEvents snapshot now keeps the latest event of each type.
  • client: projects the latest webVersion off the lifecycle stream; WebUpdateBanner compares it to the version the tab booted with and shows an unobtrusive "Reload" affordance. Never auto-reloadsvitePreloadRecovery still handles the genuinely-broken-chunk case.

Tests

  • projectServerWebVersion accumulation (ignores non-web lifecycle events).
  • isWebUpdateAvailable decision matrix.
  • vp check clean; full recursive typecheck clean.

Why draft

The reload affordance is client-visible; per the repo's client-visible-verification rule it needs a test-t3-app pass (launch env, hot-swap dist/client, confirm the banner appears and Reload works) before promoting to ready. Also pending: the no-cache/immutable header behavior is unchanged, so passive reload already works without this — this is the proactive UX layer.

🤖 Generated with Claude Code

…swap

Complements the hot-swap deploy: the server broadcasts the identity of its
served web bundle so open clients learn when their assets were swapped and can
offer a reload, instead of only reloading passively on a failed chunk import.

- contracts: add webVersionChanged to ServerLifecycleStreamEvent (payload =
  webVersion hash).
- server: webVersionWatcher polls the served index.html hash and publishes on
  change; the current version seeds the lifecycle snapshot so a connecting
  client learns the version it is running. serverLifecycleEvents keeps the
  latest event of each type in the replay snapshot.
- client: project the latest webVersion off the lifecycle stream; WebUpdateBanner
  compares it to the version the tab booted with and shows an unobtrusive
  "Reload" affordance. Never auto-reloads (vitePreloadRecovery still handles the
  genuinely-broken-chunk case).

Tests: projectServerWebVersion accumulation, isWebUpdateAvailable decision.
vp check clean; full recursive typecheck clean.

DRAFT: the reload affordance is client-visible and needs a test-t3-app
verification pass before ready.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@patroza

patroza commented Aug 2, 2026

Copy link
Copy Markdown
Owner Author

@omegent fix ci

@omegent-app

omegent-app Bot commented Aug 2, 2026

Copy link
Copy Markdown

Fixed in 7c2b11cee.

The CI failure was apps/web/src/AppRoot.test.tsx still asserting 3 top-level children after WebUpdateBanner was added to AppRoot. I updated the test to expect the new fourth child and assert that it is WebUpdateBanner.

Local verification:

  • vp test run apps/web/src/AppRoot.test.tsx

GitHub has already picked up the new SHA and reran checks on PR #294; Fork CI / Test is queued on 7c2b11ceee1811c0b7da377faeb3713c09550c7c.

gpt-5.4 · 1m 20s · ↑48k ↓197

@patroza
patroza marked this pull request as ready for review August 2, 2026 15:55
@patroza
patroza merged commit 78c4ad2 into fork/changes Aug 2, 2026
11 checks passed
patroza added a commit that referenced this pull request Aug 4, 2026
* feat(web): proactive "new version" reload affordance after a web hot-swap

Complements the hot-swap deploy: the server broadcasts the identity of its
served web bundle so open clients learn when their assets were swapped and can
offer a reload, instead of only reloading passively on a failed chunk import.

- contracts: add webVersionChanged to ServerLifecycleStreamEvent (payload =
  webVersion hash).
- server: webVersionWatcher polls the served index.html hash and publishes on
  change; the current version seeds the lifecycle snapshot so a connecting
  client learns the version it is running. serverLifecycleEvents keeps the
  latest event of each type in the replay snapshot.
- client: project the latest webVersion off the lifecycle stream; WebUpdateBanner
  compares it to the version the tab booted with and shows an unobtrusive
  "Reload" affordance. Never auto-reloads (vitePreloadRecovery still handles the
  genuinely-broken-chunk case).

Tests: projectServerWebVersion accumulation, isWebUpdateAvailable decision.
vp check clean; full recursive typecheck clean.

DRAFT: the reload affordance is client-visible and needs a test-t3-app
verification pass before ready.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* test(web): account for update banner in AppRoot

---------

Co-authored-by: Stack Test <stack-test@example.com>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com>
patroza added a commit that referenced this pull request Aug 4, 2026
* feat(web): proactive "new version" reload affordance after a web hot-swap

Complements the hot-swap deploy: the server broadcasts the identity of its
served web bundle so open clients learn when their assets were swapped and can
offer a reload, instead of only reloading passively on a failed chunk import.

- contracts: add webVersionChanged to ServerLifecycleStreamEvent (payload =
  webVersion hash).
- server: webVersionWatcher polls the served index.html hash and publishes on
  change; the current version seeds the lifecycle snapshot so a connecting
  client learns the version it is running. serverLifecycleEvents keeps the
  latest event of each type in the replay snapshot.
- client: project the latest webVersion off the lifecycle stream; WebUpdateBanner
  compares it to the version the tab booted with and shows an unobtrusive
  "Reload" affordance. Never auto-reloads (vitePreloadRecovery still handles the
  genuinely-broken-chunk case).

Tests: projectServerWebVersion accumulation, isWebUpdateAvailable decision.
vp check clean; full recursive typecheck clean.

DRAFT: the reload affordance is client-visible and needs a test-t3-app
verification pass before ready.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* test(web): account for update banner in AppRoot

---------

Co-authored-by: Stack Test <stack-test@example.com>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com>
patroza added a commit that referenced this pull request Aug 4, 2026
* feat(web): proactive "new version" reload affordance after a web hot-swap

Complements the hot-swap deploy: the server broadcasts the identity of its
served web bundle so open clients learn when their assets were swapped and can
offer a reload, instead of only reloading passively on a failed chunk import.

- contracts: add webVersionChanged to ServerLifecycleStreamEvent (payload =
  webVersion hash).
- server: webVersionWatcher polls the served index.html hash and publishes on
  change; the current version seeds the lifecycle snapshot so a connecting
  client learns the version it is running. serverLifecycleEvents keeps the
  latest event of each type in the replay snapshot.
- client: project the latest webVersion off the lifecycle stream; WebUpdateBanner
  compares it to the version the tab booted with and shows an unobtrusive
  "Reload" affordance. Never auto-reloads (vitePreloadRecovery still handles the
  genuinely-broken-chunk case).

Tests: projectServerWebVersion accumulation, isWebUpdateAvailable decision.
vp check clean; full recursive typecheck clean.

DRAFT: the reload affordance is client-visible and needs a test-t3-app
verification pass before ready.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* test(web): account for update banner in AppRoot

---------

Co-authored-by: Stack Test <stack-test@example.com>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com>
patroza added a commit that referenced this pull request Aug 5, 2026
* feat(web): proactive "new version" reload affordance after a web hot-swap

Complements the hot-swap deploy: the server broadcasts the identity of its
served web bundle so open clients learn when their assets were swapped and can
offer a reload, instead of only reloading passively on a failed chunk import.

- contracts: add webVersionChanged to ServerLifecycleStreamEvent (payload =
  webVersion hash).
- server: webVersionWatcher polls the served index.html hash and publishes on
  change; the current version seeds the lifecycle snapshot so a connecting
  client learns the version it is running. serverLifecycleEvents keeps the
  latest event of each type in the replay snapshot.
- client: project the latest webVersion off the lifecycle stream; WebUpdateBanner
  compares it to the version the tab booted with and shows an unobtrusive
  "Reload" affordance. Never auto-reloads (vitePreloadRecovery still handles the
  genuinely-broken-chunk case).

Tests: projectServerWebVersion accumulation, isWebUpdateAvailable decision.
vp check clean; full recursive typecheck clean.

DRAFT: the reload affordance is client-visible and needs a test-t3-app
verification pass before ready.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* test(web): account for update banner in AppRoot

---------

Co-authored-by: Stack Test <stack-test@example.com>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant