deno
b5c0dbbc - fix(ext/http): reject Response-like return from serve handler (#34416)

Commit
154 days ago
fix(ext/http): reject Response-like return from serve handler (#34416) ## Summary When the `Deno.serve` handler returns an object that has `Response.prototype` in its chain but doesn't carry Deno's internal slot (e.g. a subclass that skipped `super()`, or a polyfilled/foreign-realm Response), `mapped` in `ext/http/00_serve.ts` reads `inner.status` with `inner === undefined` and the whole serve loop tears down with: ``` Terminating Deno.serve loop due to unexpected error TypeError: Cannot read properties of undefined (reading 'status') at mapped (ext:deno_http/00_serve.ts:...) ``` This bug is observable with the `nitro` + `vite` Deno template (`denoland/deno#33893`, `denoland/deno#34327`) — the env-runner worker spawned by Nitro's dev server returns such an object to `Deno.serve` and the loop crashes on the very first request, surfacing as `[vite] Internal server error: socket hang up` upstream. The validation that catches this used to exist (added in #29086 and removed when the surrounding fallback was deleted in #29105). Re-add a focused check against the internal slot so this case is rejected by the existing `onError` path instead of crashing the loop. ## Test plan - New `handleServeCallbackReturnsResponseLike` + `handleServeErrorCallbackReturnsResponseLike` in `tests/unit/serve_test.ts` build a `Response`-prototyped object with no internal slot, return it from the handler / `onError`, and assert that the request still completes (recovered response / `Internal Server Error`) instead of the serve loop dying. - Existing `handleServeCallbackReturn` / `handleServeErrorCallbackReturn` tests cover the case where the handler returns a non-Response — message for that path is unchanged. Closes denoland/orchid#244 --------- Co-authored-by: divybot <divybot@users.noreply.github.com> Co-authored-by: Divy Srivastava <me@littledivy.com>
Author
Parents
Loading