Reproduction of request cancellation in workerd

[edmundhung]

I have been testing request cancellation support in Wrangler and noticed that Workerd does not log the Request was aborted message either. Is that expected?

The same worker does log the message in production.

[kentonv]

Try also adding:

    ctx.waitUntil(new Promise((resolve) => setTimeout(resolve, 4000)));

Without the waitUntil(), as soon as the client disconnects, the entire request context is torn down immediately, and hence the abort event doesn't get a chance to be delivered.

[edmundhung]

Just gave that a try in 07ecdbd, but I'm still not seeing any logs.

[jasnell]

fwiw, ctx.waitUntil(scheduler.wait(3000)) would do the same thing.

[npaun]

Doesn't seem to work locally for me either. I'll try putting a debugger on it, unless anyone has any leads.

[jasnell]

How are you testing the abort? Simply by disconnecting the requester? while the timeout is still pending?

[npaun]

How are you testing the abort? Simply by disconnecting the requester? while the timeout is still pending?

At least that's what I'm doing when trying to repro.

It's a bit of an odd situation. The request is fully sent, and no response is sent at all.

The demos I provided would have a streaming response, and the client would abort while reading, etc.

[jasnell]

Try starting to stream a response rather than just setting a timeout. Just have it where every second or so it writes a new chunk. Use the IdentityTransformStream to do it... something like...

const { writable, readable } = new IdentityTransformStream();
const writer = writable.getWriter();
const enc = new TextEncoder();
setInterval(() => writer.write(enc.encode('ping')), 1000);
ctx.waitUntil(scheduler.wait(10_000));  // 10 seconds
return new Response(readable);

And see if that makes a difference

[npaun]

@jasnell Yep, that's the "right way" and what I showed in my examples and demos.
But shouldn't @edmundhung's script work too even if it's not a very realistic use of the feature?

[jasnell]

Yep, it should. If the event is working when data is being streamed but not when we're just waiting for a timeout then that suggests the logic for detecting the disconnect is flawed. Likely it's probably only actually detecting the disconnect when the next chunk of data is being written to the socket.

[npaun]

Yep, it should. If the event it working when data is being streamed but not when we're just waiting for a timeout then that suggests the logic for detecting the disconnect is flawed. Likely it's probably only actually detecting the disconnect when the next chunk of data is being written to the socket.

This seems quite plausible...

[edmundhung]

FWIW, I have tried the exact example from the changelog but it doesn't work as well. I just simplified the example here.

[npaun]

@edmundhung I cannot reproduce that locally. I just tried the changlelog example on the latest wrangler and it still works for me.

[edmundhung]

@npaun Right. Just test it again and your demo works locally. Thanks for confirming.