test/proxy.test.ts (1)

265-290: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Use it.skipIf per repo test convention instead of it.runIf.

Guidelines mandate it.skipIf(ctx.target === "node") for runtime-specific skips, not it.runIf(target === "web"). Functionally equivalent today, but diverges from the stated convention and would silently misbehave if a third describeMatrix target is ever added (an it.skipIf("node") naturally excludes only node, whereas it.runIf("web") locks the test to web-only, excluding any future target too).

♻️ Proposed fix

-      it.runIf(t.target === "web")(
+      it.skipIf(t.target === "node")(

As per coding guidelines, test/**/*.test.ts: "Use it.skipIf(ctx.target === "node") for runtime-specific test skips".

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@test/proxy.test.ts` around lines 265 - 290, The test in proxy.test.ts uses
it.runIf(t.target === "web"), which violates the repo’s runtime-skip convention.
Update this case to use it.skipIf with the test context target check, matching
the existing matrix style and keeping the proxyRequest abort-propagation test
named and scoped consistently with the other runtime-specific tests.

Source: Coding guidelines

src/utils/proxy.ts (1)

112-116: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win

Custom fetchOptions.signal silently disables client-abort forwarding.

Because ...opts.fetchOptions is spread after signal: event.req.signal, any caller-supplied fetchOptions.signal completely replaces the forwarded client signal. That contradicts the new doc comment's claim that the incoming signal is "always forwarded" (Lines 25-27) — in practice, once a custom signal is set, client disconnects no longer abort the upstream request at all, defeating the feature this PR introduces.

Consider merging the two signals with AbortSignal.any() so the client abort is always honored regardless of a custom signal:

♻️ Proposed fix using AbortSignal.any

   const fetchOptions: RequestInit = {
-    signal: event.req.signal,
     headers: opts.headers as HeadersInit,
     ...opts.fetchOptions,
+    signal: opts.fetchOptions?.signal
+      ? AbortSignal.any([event.req.signal, opts.fetchOptions.signal])
+      : event.req.signal,
   };

Also worth relaying: this is also related to the still-open feedback from iainsproat on the previous commit asking whether forwarding should be gated behind an option — the forwarding remains unconditional in this version.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/utils/proxy.ts` around lines 112 - 116, The proxy request setup in
`src/utils/proxy.ts` currently lets `opts.fetchOptions.signal` overwrite
`event.req.signal`, so client-abort forwarding is lost whenever a custom signal
is provided. Update the `fetchOptions` assembly in the proxy helper to preserve
the incoming request signal and combine it with any caller-supplied signal,
ideally in the same place where `fetchOptions` is built. Use the
`event.req.signal` and `opts.fetchOptions.signal` values together so upstream
requests still abort on client disconnect even when custom fetch options are
passed, and make sure the behavior matches the doc comment’s “always forwarded”
guarantee or add a gate if that’s the intended contract.

src/utils/proxy.ts (1)

188-231: 🚀 Performance & Scalability | 🔵 Trivial | ⚖️ Poor tradeoff

Response body is wrapped on the default hot path for every proxied response.

Since propagateAbortError defaults to false, quietlyAbortableStream wraps the upstream body for all successful responses, not just aborted ones. Each chunk is now pumped through a JS pull loop (reader.read() → enqueue) instead of handing the native stream straight to HTTPResponse, adding per-chunk overhead and losing byte-stream (type: "bytes"/BYOB) semantics. For a proxy this is a throughput-sensitive path — worth measuring, or scoping the wrap to only kick in on abort.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/utils/proxy.ts` around lines 188 - 231, The default proxy response path
in `src/utils/proxy.ts` always wraps successful upstream bodies with
`quietlyAbortableStream`, which adds per-chunk JS pumping overhead and drops
native byte-stream/BYOB behavior even when no abort occurs. Update the
`HTTPResponse` body selection logic so `quietlyAbortableStream` is only used
when abort handling is actually needed, or otherwise preserve the original
`response.body` on the hot path while keeping the abort-suppression behavior in
`quietlyAbortableStream` for client disconnects.