🐛 Bug Report — Need a disconnect hook for streaming response

[rikka0w0]

According to the Workers documentation and examples, a Worker can return a ReadableStream in the fetch() handler to provide streaming responses. I’m trying to implement Server-Sent Events that periodically push data to the client, and log a message on the Worker when the client disconnects the GET request.

However, it seems impossible to detect when the client disconnects. The Worker runtime never notifies the ReadableStream returned in the response about the termination.

Below is a minimal reproduction:

export default {
	async fetch() {
		const feedthroughStream = new TransformStream();
		const writer = feedthroughStream.writable.getWriter();
		await writer.ready;
		const encoder = new TextEncoder();
		let i = 0;
		let timer = setInterval(async () => {
			await writer.write(encoder.encode(`Value: ${i}\n`));
			i++;

			if (i >= 10) {
				clearInterval(timer);
				await writer.close();
			}
		}, 1000);
		writer.closed.then(()=>console.log("writer.closed.then"));
		writer.closed.catch(()=>console.log("writer.closed.catch"));
		writer.closed.finally(()=>console.log("writer.closed.finally"));

		return new Response(feedthroughStream.readable, {
			status: 200,
			headers: {
				"X-Accel-Buffering": "no",
				"Cache-Control": "no-store",
				"Content-Type": "text/event-stream",
				"Transfer-Encoding": "chunked",
			}
		});
	}
}

When using curl on Linux, if I let the stream finish naturally, the Worker logs the expected writer.closed.then and writer.closed.finally.
But if I terminate curl early (client abort), no callbacks fire — the Worker runtime never closes the ReadableStream, so there is no way to detect client disconnect.

A similar issue has been reported here:

https://discord.com/channels/595317990191398933/1357179249152364614

It would be extremely helpful if Workers exposed a way to detect when a streaming response is aborted by the client, or automatically closed the ReadableStream.

Thanks!

[rikka0w0]

I just found this post:

https://developers.cloudflare.com/changelog/2025-05-22-handle-request-cancellation/

There seems to be a workaround:

request.signal.addEventListener('abort', () => {
	console.log('The request was aborted!');
	writer.close();
});

Inserting this just before return makes everything work as expected.

[rikka0w0]

However, another BUG persists. When I close the WritableStream (with writer.close()) after receiving the "abort" event, the Cloudflare runtime does not send a 0-byte chunk to signal the end of the streaming response. This 0-byte chunk can be observed in the case where the WritableStream finishes supplying all its data and decides to close itself (again, with writer.close())

[marko1010]

how can it send a 0-byte chunk if the connection is already closed?

[rikka0w0]

how can it send a 0-byte chunk if the connection is already closed?

If the client actively wants to disconnect a streaming GET, these are supposed to happen:

1. The client JavaScript calls EventSource.close() (e.g., in case of a server-sent event)
2. The client browser sends a TCP FIN to the server (Cloudflare Worker runtime). A FIN indicates that the client won't send anything to the server anymore. In a GET, the client never sends anything. In this case, it means the client wants to end the connection.
3. The server got the FIN and replies with ACK. At this stage, the client->server path has already been closed (if any), but the server->client path remains open. (TCP supports half-closed connections)
4. The server (Cloudflare Worker runtime) sends a 0-byte chunk to indicate "end of the stream", and then sends a TCP FIN to the client.
5. The client replies with ACK. Now, the TCP connection is considered fully closed.

If we consider request.signal, what happens:

1. The client JavaScript calls EventSource.close().
2. The client browser sends a TCP FIN to the server.
3. The Cloudflare Worker runtime got the FIN and replies with ACK.
4. The Cloudflare Worker runtime signals request.signal to the worker instance.
5. The Cloudflare Worker runtime sends a TCP FIN to the client, without sending the 0-byte chunk.
6. The client replies with ACK. Now, the TCP connection is considered fully closed.

Note: I'm not sure about the order of 4 and 5.

The expected events are:

1. The client JavaScript calls EventSource.close().
2. The client browser sends a TCP FIN to the server.
3. The Cloudflare Worker runtime got the FIN and replies with ACK.
4. The Cloudflare Worker runtime sends a 0-byte chunk with TCP FIN to the client.
5. The Cloudflare Worker runtime signals request.signal to the worker instance.
6. The client replies with ACK.

H2

TCP FIN is replaced with RST_STREAM(CANCEL) in case of an H2 connection. H2 streams also support half-close.