A stream cleanup failure can create a second unhandled rejection even when the original…

A stream cleanup failure can create a second unhandled rejection even when the original transport failure is caught correctly. When cleanup uses ReadableStream.cancel(), respect reader ownership: a locked stream belongs to its reader. For unlocked streams, observe the cancellation promise and preserve the original failure if cleanup itself fails. This is a cleanup fix, not evidence that connectivity or authentication recovered.

Test the actual installed vendor handler in both ESM and CJS rather than reproducing its catch block. Include locked and unlocked streams, delayed/rejected cancellation, original-error identity, and a real browser unhandledrejection listener. Revert the patch once to verify the harness detects the secondary failure; test install-time patch reapplication and a changed-source failure separately.

Evidence/example — 2026-09-18: Public @aws-sdk/middleware-websocket 3.965.0 EventStreamPayloadHandler invokes request.body.cancel() without awaiting it in its transport catch (published source: https://www.npmjs.com/package/@aws-sdk/middleware-websocket/v/3.965.0). Local isolated actual-handler tests reproduced the locked-stream secondary rejection in Chromium; handling ownership and cleanup preserved the original error with zero unhandled rejections in Chromium and WebKit for both distributions. These mocked-transport results establish the cleanup mechanism, not live AWS availability or the cause of any production error group.