Fix status code for prerendered pages

[FedOken]

The prerender server now always returns 200 OK when page HTML is successfully rendered.

• If resp.redirect exists, the server returns 301 via res.redirect(301, ...)
• If resp.errorCode exists, the server returns that code via res.sendStatus(resp.errorCode)], for example 500, 504).
• If err is thrown, it is passed to error handling next(err), typically resulting in 5xx.

Rendered pages always return 200, so API-side 4xx/5xx no longer leak into the final HTTP status if content was rendered.

[philippem]

we should pass through 5xx errors to the client

[FedOken]

• If resp.redirect exists, the server returns 301 via res.redirect(301, ...)
• If resp.errorCode exists, the server returns that code via res.sendStatus(resp.errorCode)], for example 500, 504).
• If err is thrown, it is passed to error handling next(err), typically resulting in 5xx.

[FedOken]

    if (err) return next(err)
    if (resp.redirect) return res.redirect(301, baseHref + resp.redirect)
    if (resp.errorCode) {
      console.error(`Failed with code ${resp.errorCode}:`, resp)
      return res.sendStatus(resp.errorCode)
    }

[shesek]

I don't quite understand what you were trying to do here. resp.status is explicitly set to handle cases where the app renders the page not found or error views, and should be forwarded to the client.

so API-side 4xx/5xx no longer leak into the final HTTP status

This is intentional, a 404 from the API backend for the resource being viewed should result in a 404 from the pre-renderer server.

[FedOken]

I don't quite understand what you were trying to do here. resp.status is explicitly set to handle cases where the app renders the page not found or error views, and should be forwarded to the client.

so API-side 4xx/5xx no longer leak into the final HTTP status

This is intentional, a 404 from the API backend for the resource being viewed should result in a 404 from the pre-renderer server.

The HTTP status code describes the result of the HTTP request itself, not the internal business logic. If the server successfully rendered a page with a user-friendly error message, from the HTTP perspective that's a 200 — the client got a valid response.

Also, blindly passing through every API status doesn't always make sense — a 400 means the client sent a bad request, but the end user didn't send a bad request, they just navigated to a page. Same with 404 — the page route exists and the server handled it, it's just that the specific block hash wasn't found in the API. That's application-level "not found", not HTTP-level. The server still found the route, rendered the view, and returned a valid HTML response.

We do handle specific cases separately before the render:

• err — passed to the error middleware via next(err)
• resp.redirect — returns a 301 redirect
• resp.errorCode — returns the exact status code without rendering

If none of those match, we proceed to render the page — and at that point the server successfully produced a response, so 200 is the correct status.