Re-render a module failure that the host shell moved under - #5934
Draft
backspace wants to merge 1 commit into
Draft
Re-render a module failure that the host shell moved under#5934backspace wants to merge 1 commit into
backspace wants to merge 1 commit into
Conversation
The indexer stores a failed render as the card's content, which is right when the card is broken and wrong when the page that rendered it was running a bundle the realm server has already stopped serving. A prerender tab holding the pre-deploy host bundle, rendering post-deploy realm source, throws `has no exported member` — a fact about a transient bundle mismatch. Persisted as an error document it becomes what every anonymous reader gets, in ~25ms from cache, until an unrelated reindex happens to revisit the row. Twice in three days that turned a bundle-coexistence window of a few minutes into an outage of roughly seventy. The prerender server is the only party that can tell those apart, because it is the one that learns the shell changed. It now reads its adopted host-shell token when a visit starts and again when the render returns, and a visit whose two tokens differ AND whose result is a module-resolution failure is rendered once more before being returned. The recycle that moved the token is already in flight by then, so the second attempt lands on a page warmed against the current shell. One attempt only: if it fails again the failure is the card's, and the caller is owed an answer. The tokens are recorded on the response either way. On a failure they are the evidence for how it should be read; on a success they let an operator attribute a render to a bundle without matching timestamps against deploy logs. Two limits worth stating. A render that both starts and finishes before this server hears about the change still looks steady to it — narrowing that needs the token stamped per page rather than per server. And a page that warmed its shell from a realm-server task that had not rolled yet carries a token that never appears to move at all; the cross-artifact CI guard is what removes that class rather than this. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
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.
This relates to the Tuesday production hosted site downtime, which happened again today.
Claude: The indexer stores a failed render as the card's content, which is right when the card is broken and wrong when the page that rendered it was running a bundle the realm server has already stopped serving. A prerender tab holding the pre-deploy host bundle, rendering post-deploy realm source, throws
has no exported member— a fact about a transient bundle mismatch. Persisted as an error document it becomes what every anonymous reader gets, in ~25ms from cache, until an unrelated reindex happens to revisit the row. Twice in three days that turned a bundle-coexistence window of a few minutes into an outage of roughly seventy.The prerender server is the only party that can tell those apart, because it is the one that learns the shell changed. It now reads its adopted host-shell token when a visit starts and again when the render returns, and a visit whose two tokens differ AND whose result is a module-resolution failure is rendered once more before being returned. The recycle that moved the token is already in flight by then, so the second attempt lands on a page warmed against the current shell. One attempt only: if it fails again the failure is the card's, and the caller is owed an answer.
The tokens are recorded on the response either way. On a failure they are the evidence for how it should be read; on a success they let an operator attribute a render to a bundle without matching timestamps against deploy logs.
Two limits worth stating. A render that both starts and finishes before this server hears about the change still looks steady to it — narrowing that needs the token stamped per page rather than per server. And a page that warmed its shell from a realm-server task that had not rolled yet carries a token that never appears to move at all; the cross-artifact CI guard is what removes that class rather than this.