Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Middleware exceptions escape the generated handleRequest and bypass configureServerErrors

未关闭
  • 哪里不对？
#382 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
typescript, vite
领域
api, backend

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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.

主要语言
TypeScript
星标
520
派生
70
平均合并
21 小时 42 分钟
30 天内合并 PR
36

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

solidjs/solid-vite-plugin 的其他 Issue

查看 solidjs/solid-vite-plugin 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。