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>