You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit fe11405
Browse filesBrowse the repository at this point in the historyBrowse files
Improve Start response reconciliation, session cookie handling, and server-entry error recovery. Server entries now recover Start error responses with `handleStartError`, response helpers reconcile across server routes, SSR, server functions, redirects, and error responses, and serialized server-function transport headers are protected from helper overrides.
Whether we are statically generating our app or serving it dynamically, the `server.ts` file is the entry point for doing all SSR-related work as well as for handling server routes and server function requests.
37
37
38
+
## Configuring a Custom Server Entry
39
+
40
+
By default, Start uses the generated server entry. If you provide your own server entry at a non-standard path, configure it in your bundler plugin. The `server.entry` path is resolved relative to `srcDirectory`, which defaults to `src`.
The generated server entry catches uncaught errors and calls `handleStartError(error)`. Response helpers such as `setResponseStatus`, `setResponseHeader`, and `setCookie` are reconciled onto the error response.
114
+
115
+
This default behavior means Start owns the uncaught-error boundary. If a loader, server route, or middleware throws after setting response state, Start still returns a valid `Response` with the intended status, headers, and cookies. Server function RPC errors are handled before this top-level boundary so the client protocol response stays intact.
116
+
117
+
For example, this should return `401`, not a generic `500`:
This conversion does more than create a plain `new Response(...)`. It preserves response state that Start captured during the request:
134
+
135
+
- Status and status text from `setResponseStatus`
136
+
- Headers from `setResponseHeader` and `setResponseHeaders`
137
+
- Cookies from `setCookie`, including multiple `Set-Cookie` headers
138
+
- HTTP-style error metadata such as `error.status`, `error.statusText`, `error.headers`, and `error.cause.headers`
139
+
- Protocol headers used by server function responses
140
+
- Null-body response rules for `HEAD`, `204`, `205`, and `304`
141
+
142
+
`createStartHandler(...)` rethrows uncaught errors after associating them with the current Start request. If you write a custom server entry and need custom top-level error handling, catch around the returned fetch handler and call `handleStartError(error)` yourself:
// Add logging, reporting, or custom branching here.
161
+
returnhandleStartError(error)
162
+
}
163
+
},
164
+
})
165
+
```
166
+
167
+
Use `handleStartError(error)` when you want custom top-level logic, such as logging or reporting, but still want Start to produce the same error response as the generated server entry.
168
+
169
+
`handleStartError(error)` is useful because the error is caught outside the active Start handler. It recovers the Start request state associated with non-primitive thrown errors and reconciles that state onto the error response. Primitive throws cannot carry that association.
170
+
171
+
If you do not want to preserve response helpers that ran before the error, do not call `handleStartError`. Return your own response instead:
returnnewResponse('Internal Server Error', { status: 500 })
190
+
}
191
+
},
192
+
})
193
+
```
194
+
195
+
Use this pattern when your server entry or deployment platform should fully own the error response and should ignore any status, headers, or cookies set earlier in the Start request.
196
+
63
197
## Request context
64
198
65
199
When your server needs to pass additional, typed data into request handlers (for example, authenticated user info, a database connection, or per-request flags), register a request context type via TypeScript module augmentation. The registered context is delivered as the second argument to the server `fetch` handler and is available throughout the server-side middleware chain — including global middleware, request/function middleware, server routes, server functions, and the router itself.
0 commit comments