toWebRequest is not creating abort signal

[IlyaSemenov]

Environment

• h3@1.15.3
• Node v22.16.0

Reproduction

The problem is clear by looking at the code — the signal property is not created:

h3/src/utils/request.ts

Lines 354 to 365 in ec77d6b

	export function toWebRequest(event: H3Event) {
	return (
	event.web?.request ||
	new Request(getRequestURL(event), {
	// @ts-ignore Undici option
	duplex: "half",
	method: event.method,
	headers: event.headers,
	body: getRequestWebStream(event),
	})
	);
	}

I would have created a demo reproduction with trpc-nuxt but StackBlitz currently has a problem running Nuxt apps, will do once nuxt/nuxt#33120 is fixed.

Describe the bug

toWebRequest is not creating the abort signal (which other libraries depend upon). That makes the code that uses the web requests created from h3 events to stuck forever when e.g. handling subscriptions.

Related issue: wobsoriano/trpc-nuxt#191

Additional context

I extended toWebRequest to pass the AbortSignal to work around the issue:

function toWebRequest(event: H3Event) {
  return event.web?.request || new Request(getRequestURL(event), {
    // @ts-ignore Undici option
    duplex: "half",
    method: event.method,
    headers: event.headers,
    body: getRequestWebStream(event),
    signal: (() => {
      const abortController = new AbortController()
      event.node.req.on("close", () => abortController.abort())
      return abortController.signal
    })(),
  })
}

Logs

[pi0]

Thanks for the report. Feel free to open a PR for adding support.

Only we have to make sure signal is lazy created. Check h3js/srvx#76 as reference

[kricsleo]

@IlyaSemenov Do you have any plans to work on this? If not, I'd be happy to fix it ❤️

[IlyaSemenov]

Sure, please do. If it were hanging like this for some time more, I could at some point pick it up, but if you're willing to fix this, please go ahead!

[productdevbook]

@pi0 This is labeled v1. In v2, toWebRequest no longer exists — event.req IS already a web standard Request object (via srvx). The abort signal comes from the platform's native Request.signal.

There's also an open PR #1220 targeting this for v1. Can this be closed as not applicable to v2?