Bun.serve response streaming and idempotency during client retries

When implementing high-throughput APIs using Bun.serve, the use of ReadableStream allows for efficient data transmission by avoiding full payload buffering. However, in scenarios where a client initiates a retry due to a perceived timeout or network flicker while a stream is already active, the server may continue processing the original request while simultaneously starting a new one.

Because Bun.serve operates on a high-performance native event loop, the timing of request cancellation and the subsequent cleanup of associated asynchronous resources must be precisely managed to prevent duplicate side effects, such as redundant database writes via bun:sqlite.

What is the documented mechanism for detecting a disconnected client during an active stream to halt further processing? How does Bun handle the lifecycle of the request handler when a retry occurs before the initial stream is fully closed?