fix(paddock): stamp the shell served at / too, and adopt a build when unstamped - #70
Merged
Conversation
… unstamped #69 stamped the build id only on the SPA fallback path. `/` maps straight to `index.html` and was served as a bare file, so every tab loaded from the root -- which is every tab -- carried no <meta name="paddock-build">, sent no x-paddock-build header, and was turned away from the strip with 409 stale_client by the very check meant for OLD bundles. Verified in production after the roll: the header and /api/config named the build, the HTML did not. - serveStatic routes `/` and `/index.html` through the stamped shell like every client-side route; the test now covers all three paths and fails without the fix. - A tab whose HTML carried no stamp adopts the first build a response names and sends it from then on, so a current bundle can never be permanently refused by a server that stamps. The cost is the sub-second window between the HTML and its first API answer, in which a deploy would leave that tab not reloading until the deploy after -- far cheaper than the failure this guards against. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018R1XyyWd9MDMYXqFL71owk
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why (live regression from #69, found in production after the roll)
#69 stamped the build id only on the SPA fallback path.
/maps straight toindex.htmland was served as a bare file, so every tab loaded from the root (which is every tab) carried no<meta name="paddock-build">, sent nox-paddock-buildheader, and was turned away from the strip with 409stale_clientby the very check meant for old bundles. Checked against paddock.demo.managoat.com after the rollout: thex-paddock-buildheader and/api/confignamed the build, the HTML did not.Consequence while it stands: a freshly loaded tab never gets a strip, and an owner's boot sees no box and sends the bootstrap turn as an extra tab on the existing machine.
What changed
serveStaticroutes/and/index.htmlthrough the stamped shell like every client-side route. The test now covers all three paths and fails without the fix (checked by stashing the server change).src/lib/build.ts: a tab whose HTML carried no stamp adopts the first build a response names and sends it from then on, so a current bundle can never be permanently refused by a server that stamps. The cost is the sub-second window between the HTML and its first API answer, in which a deploy would leave that tab not self-reloading until the deploy after; far cheaper than the failure this guards against.222 pass,
tsc --noEmitandbun run buildgreen locally.🤖 Generated with Claude Code
https://claude.ai/code/session_018R1XyyWd9MDMYXqFL71owk