Describe the problem

When a request comes into a SvelteKit app, and that results in outgoing requests or other asynchronous operations as part of serving it, and then the incoming connection is closed (due to a load balancer or reverse proxy timeout or any other reason), then all of those asynchronous operations continue to wastefully run, working on a response that it's not going to be able to return.

Additionally, any logs generated by the SvelteKit application about response latencies are going to be inaccurate if the client or upstream server has already hung up.

Describe the proposed solution

Perhaps an AbortSignal present on the event object? If the incoming connection is closed, SvelteKit would trigger it. It would then be the app's responsibility to do whatever they wanted with this - passing it to outgoing fetches, say, or doing whatever else it deems appropriate when the signal's abort event fires.

Alternatives considered

We could do this without increased API surface area by making the closing of the incoming request automatically abort any outgoing requests triggered by the SvelteKit-owned event.fetch. However, this wouldn't provide the primitives for doing other non-fetch based things that should be canceled, and it wouldn't allow the user to opt in to keep specific outgoing requests going even when the incoming request has been canceled.

Importance

nice to have

Additional Information

I don't know what this would look like for things other than the Node adapter. Does the lambda/whatever function used in other environments get information about the incoming connection getting closed? Or do they just abort the whole function/process that was handling the request, implicitly aborting any of the async operations it was doing?