When a route's data step fails, how does the rendering mode change what the visitor receives?
answer
- who is running, and what has been sent
- build-time failure has no visitor
- commit fixes the status
- regeneration degrades to stale, not to error
- status alerts miss three of four modes
basics
~20 sThe mode decides whether code is running and whether bytes were sent. A prerendered route fails at build; a per-request route picks a status or redirects; a streamed route already promised 200; a regenerated one serves its last good copy.
solid answer
~50 sTwo facts decide everything: is your code running when the failure happens, and has the response been committed? For a **prerendered** route the data step ran at build time, so the failure is a build event — the build fails or the route is left unbuilt — and at request time there is no server to produce a 500 or decide a redirect. A **per-request** render has full freedom: catch, pick a status, render the fallback error page, or redirect instead. A **streamed** route flushed its shell with 200 already, so a later failure can only appear inside the body. A **regenerated** prerender keeps answering from the last good copy while the refresh fails behind it, so the visitor sees success and staleness. That also decides how you monitor each: status alerts only cover the per-request case.
go deeper
Remember that a page built ahead of time has no code running when a visitor arrives, so its data failures happen during the build rather than in front of the user.
Explain each mode against two questions — is code running, and have headers been sent — and describe the outcome each combination allows, including the streamed case where the status is already fixed.
Show that monitoring follows the mode: build and deploy alerts for prerendered routes, staleness metrics for regenerated ones, explicit error reporting for streamed ones, status alerts only where the status is honest.
Own the tradeoff as a policy. Decide per route class whether availability with stale data beats accurate failure reporting, write down a maximum acceptable staleness, and keep routes with machine consumers out of modes whose status can lie.
## Failure has to happen somewhere, and the mode decides where Every rendering mode answers the same question differently: **at the moment the failure occurs, is there code of yours running, and has anything been sent to the client yet?** Those two facts determine the entire set of outcomes available. ### Prerendered at build time The data step for a prerendered route runs **during the build**, on a machine no user is waiting on. If the fetch fails there, the failure is a build event: the build stops, or the route is left unbuilt, or the framework emits the route with whatever fallback the project configured. What does *not* happen is a 500 at request time, because at request time the route is a file and nobody is home to produce one. A visitor gets one of: the previously deployed artifact (if the pipeline keeps the last good deploy), the host's own missing-file response, or a stale page built from stale data — and none of those is chosen by your error handling. The corollary trips teams up regularly: **a prerendered route cannot make a per-request decision at all**, so it cannot return a status computed from this request, and it cannot decide to redirect this particular visitor. Any such behaviour has to come from the hosting layer's own rules or from moving the route to a per-request mode. ### Rendered per request This is the mode with full freedom, and it is the mental model most people carry by default. Code is running, nothing has been sent, so the framework can catch the failure, choose a status, render the route's fallback error page, or abandon the render and answer a redirect instead. Failures are visible in request logs with the status attached, which is why status-based alerting works well for this mode and poorly for the others. ### Streamed Streaming sends the shell early to improve perceived latency, which means the status line and headers are already committed when the slower parts of the page resolve. A failure arriving then **cannot change the status**; it can only be expressed in the remaining body — an inline error region where the content should have been, or an abruptly terminated response that the client sees as a truncated document. The response says 200 and the page says something went wrong. ### Regenerated prerender A route that was prerendered and is refreshed after a window, or on demand, has a stored copy that answers requests. When a refresh fails, the sane behaviour — and the common one — is to **keep serving the last good copy**. Users see success, possibly with increasingly stale data, and the failure exists only in logs and metrics. Silent staleness is the price of the mode's availability. ## Side by side | Mode | When failure lands | What the visitor gets | Where you see it | |---|---|---|---| | Prerendered | build time | last good deploy, host's missing-file response, or stale content | build logs, pipeline status | | Per request | during the request, before commit | error page with a chosen status, or a redirect | request logs, status metrics | | Streamed | after commit | 200 with an error region or a truncated body | client-side reports, server logs | | Regenerated | during background refresh | the previous copy, silently stale | refresh logs, staleness metrics | ## What this means for how you operate a site 1. **Alert on the right signal per mode.** Status-code alerting covers only per-request routes. Prerendered routes need build and deploy alerting; regenerated ones need staleness or refresh-failure alerting; streamed ones need an explicit client-side or server-side error report, since their status lies. 2. **Choose the mode with failure in mind, not only latency.** A route that must report failure accurately to a machine consumer is a poor candidate for streaming. A route whose data source is flaky is a good candidate for regeneration, precisely because a failed refresh degrades to stale rather than to an error. 3. **Put fallible work before the first flush.** On a streamed route, the checks whose failure must change the status — existence, permission-dependent redirects, malformed input — belong in the part that runs before the shell goes out. 4. **Decide explicitly what stale means.** Serving the last good copy forever is not obviously right: some content is better missing than wrong. That is a product decision, and it should be written down as a maximum acceptable staleness rather than inherited from a default. 5. **Do not assume a fallback page can save you.** The route's fallback error page is still a body; it only carries a 5xx when the failure was known before the response committed. The compact way to say all this in an interview: *a prerendered route fails at build, a per-request route fails into a status, a streamed route fails into a body it has already promised was fine, and a regenerated route fails into staleness.*
- Why does status-code alerting give a false sense of safety on a mostly prerendered site?Because most failures never reach a status. A prerendered route's data failure lands in the build, and a failed regeneration lands in a background job, so the request-side dashboard keeps showing healthy 200s while the content is missing or stale. Those modes need build alerts and staleness metrics instead.
- If a streamed route must report failure accurately, what do you change?Move the work whose failure must change the status ahead of the first flush — existence checks, authorisation-driven redirects, input validation — and stream only the parts whose failure you are willing to render inline. If most of the page is in that fallible category, the route is a poor fit for streaming and should render per request.
- Is serving the last good copy after a failed refresh always the right default?No. It buys availability at the cost of correctness, which suits marketing and catalogue content but not prices, stock levels or anything with legal weight. Decide a maximum acceptable staleness per route, and for the routes where wrong is worse than missing, prefer failing visibly to serving an old copy indefinitely.
It is the difference between a printing error caught in the print shop, a waiter who can still change your order, a waiter who has already served the starter, and a shop that keeps selling yesterday's loaf because today's bake failed.
saying these in an interview costs you the question
- Expects a prerendered route to return 500 at request time
- Thinks a prerendered route can redirect a particular visitor
- Believes a streamed route can switch its status mid-body
- Assumes a failed regeneration shows users an error page
- Relies on status dashboards to catch build-time data failures
- Treats the fallback error page as proof the status is right