Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Middleware exceptions escape the generated handleRequest and bypass configureServerErrors

Đã đóng
  • Có gì không ổn?
#382 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript, vite
Lĩnh vực
api, backend

Hướng nghiên cứu

Start by reading src/ssr/index.ts around lines 1433-1453 and compare the server-function endpoint's handling of thrown Responses. Reproduce the production /boom case, then inspect src/node-entry/index.ts and the configureServerErrors path. Done means production middleware failures follow the stated response and error-policy behavior while dev retains its current overlay behavior.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Problem

In Start mode, the generated handleRequest runs the start.middleware chain without a catch:

https://github.com/solidjs/solid-vite-plugin/blob/52d93ebcf2cd41d1254cbf8ab32f51b0b0b11d85/src/ssr/index.ts#L1433-L1453

When a middleware throws or rejects in a production build, the exception leaves handleRequest and each host deals with it in its own way:

  • Nitro (h3) logs the original error with console.error and answers 500 with {"error":true,"status":500,"unhandled":true} as JSON. The headers and cookies the chain already wrote to the response stub are lost.
  • start.node logs it and answers a plain-text 500 (src/node-entry/index.ts#L154-L161).
  • The examples/start-ssr server sends e.message back to the client (examples/start-ssr/server.js#L78-L81).

Two consequences go beyond the inconsistent response:

  1. The hook registered with configureServerErrors({ onError }) never sees these failures, although its docs describe it as seeing "the failure that fails a request". Apps that rely on it to keep original errors out of logs, or to forward them to an APM (as start.instrument in #365 suggests), lose that for middleware, API handlers mounted in middleware, and start.setup / start.renderMode failures.
  2. A thrown control response turns into a 500. return redirect('/login') from a middleware works, but throw redirect('/login') reaches h3 as a non-Error rejection and becomes an unhandled 500. The server-function endpoint, served by the same handler, already treats a thrown Response as the response.
Reproduction

With @solidjs/vite-plugin 3.0.0-next.46, @solidjs/web 2.0.0-rc.11 and Nitro 3 beta:

// the module passed to start.middleware
export default async function middleware(request: Request, next: () => Promise<Response>) {
  if (new URL(request.url).pathname === '/boom') throw new Error('token=abc123')
  return next()
}

Build for production, serve it and request /boom: the response is Nitro's JSON 500, the server log shows Error: token=abc123 with its stack, and a hook registered with configureServerErrors is not called.

Expected

In production builds, the generated handler contains request failures the way the server-function endpoint does:

  • a thrown Response (except Response.error()) or response envelope becomes the response;
  • anything else goes through the configured server error policy and yields a generic 500 that still carries the stub's headers and cookies;
  • dev keeps the current behavior, so the Vite overlay still shows the original error.
Notes
  • There is no public API today to run a value through the configured policy outside a render, so the handler would have to call the hook registered under the configureServerErrors symbol. A public entry point in @solidjs/web for request failures, with its own kind in ServerErrorSite, would remove that coupling.
  • A later step could render the app's error boundary when the chain fails before the page render, so a failed navigation gets an HTML error page instead of an empty 500. Apps can do that in userland today, but it depends on the single-render rule and on excluding the server-function endpoint.
  • Related: #328, since a deploy adapter would benefit from a handler that does not reject for application failures.

I'll follow up with a PR for the containment part.

Ngôn ngữ chính
TypeScript
Star
522
Fork
72
Merge trung bình
1 ngày 8 giờ
Pull request đã merge (30 ngày)
29

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của solidjs/solid-vite-plugin

Tất cả issue của solidjs/solid-vite-plugin

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.