Fix/images stream writer error - ERR_STREAM_DESTROYED #1969

Arctic-beaver · 2025-10-23T13:54:18Z

Prevent unhandled stream errors on media upload - ERR_STREAM_DESTROYED error

Summary

Under heavy load (100+ concurrent proxy’d connections) media uploads could crash with unhandled stream errors.
When the remote side closed the HTTP response mid-transfer, our readable ended while the file Writable still had in-flight fs.write ops. We called destroy() on the writable, and those pending writes later completed against a destroyed stream → ERR_STREAM_DESTROYED surfaced as an unhandled error.

This PR makes streaming robust by:

handling backpressure (drain) on every write,
awaiting finish/close before teardown,
using safe, idempotent cleanup,
and converting the race into a well-defined, awaited shutdown.

Context / Symptoms

Happened during bursts of image sends while proxies were flapping.

Representative logs:

TypeError: terminated: other side closed
  at ... undici ...
caused by: SocketError: other side closed

Followed by a low-level write error:

Error [ERR_STREAM_DESTROYED]: Cannot call write after a stream was destroyed
  at node:internal/fs/streams:426:23

Full errores:

"type":"Error","message":"Cannot call write after a stream was destroyed","stack":"Error [ERR_STREAM_DESTROYED]: Cannot call write after a stream was destroyed\n at node:internal/fs/streams:426:23\n at FSReqCallback.wrapper [as oncomplete] (node:fs:824:5)\n at FSReqCallback.callbackTrampoline (node:internal/async_hooks:130:17)","code":"ERR_STREAM_DESTROYED"},"msg":"Cannot call write after a stream was destroyed"

15-10 10:43:25.324: {"level":30,"time":1760514205269,"pid":19132,"hostname":"Ghostly","req":{"method":"POST","url":"/messages/send/file?instanceId=112501","query":{"instanceId":"112501"},"params":{},"headers":{"host":"localhost:20001","traceparent":"00-2a7caada3da1b345a5d33642e9125055-4f0bf49785953fef-00","content-type":"application/json; charset=utf-8","content-length":"1512"}}}

Root cause

undici aborts the fetch when the remote side closes: we correctly hit catch.
Our error path immediately called fileWriteStream.destroy().
But previous fileWriteStream.write() calls are non-blocking: they schedule fs.write via libuv. Those callbacks can still fire after destroy().
Without an error listener and without awaiting finish/close, the completion of those writes throws on a destroyed stream → unhandled rejection → process crash.

This is a classic race between readable failure and writable pending I/O.

What I changed (high level)

Backpressure-aware writes
- Wrap writes into async writeChunk(); if .write() returns false, await 'drain' before continuing.
Reliable stream finalization
- Introduce waitForCloseOrFinishStream(stream) and await it where we previously did .end()/.destroy().
- Replace imperative destroy() + hope with Promise.allSettled([ wait(encFile), wait(origFile) ]).
Graceful error path
- On error: try .destroy() (guarded), then await finish/close on involved streams, then unlink temp files.
- Make cleanup idempotent and exception-safe (try/catch around every step).
Hashing & return semantics
- Ensure hashing/finalization only after write stream has fully finished (post-finish/close).

Why this fixes it

Pending fs.write completions now resolve against a stream that we explicitly let finish (or at least reach close) instead of a just-destroyed instance.
All writes respect backpressure; we never overrun the writable’s internal buffer during spikes.
Teardown paths are awaited, idempotent, and cannot leak unhandled errors to the global handler.

Load conditions where it used to fail

100+ concurrent sends through proxies
Rapid proxy disconnects (“other side closed”) during fetch body consumption
Concurrent readable abort while writable still flushing to disk

Risk & compatibility

Low behavioral risk; logic is more conservative about awaiting I/O completion.
No external API changes.
Tested locally under forced aborts and with parallel uploads; now yields clean, handled errors and no process-level crashes.

Updating branch

whiskeysockets-bot · 2025-10-23T13:54:33Z

Thanks for opening this pull request and contributing to the project!

The next step is for the maintainers to review your changes. If everything looks good, it will be approved and merged into the main branch.

In the meantime, anyone in the community is encouraged to test this pull request and provide feedback.

✅ How to confirm it works

If you’ve tested this PR, please comment below with:

Tested and working ✅

This helps us speed up the review and merge process.

📦 To test this PR locally:

# NPM
npm install @whiskeysockets/baileys@Arctic-beaver/Baileys#fix/images-stream-writer-error

# Yarn (v2+)
yarn add @whiskeysockets/baileys@Arctic-beaver/Baileys#fix/images-stream-writer-error

# PNPM
pnpm add @whiskeysockets/baileys@Arctic-beaver/Baileys#fix/images-stream-writer-error

If you encounter any issues or have feedback, feel free to comment as well.

…R_STREAM_DESTROYED - Add proper stream cleanup with waitForCloseOrFinishStream - Use Promise.allSettled for safe stream closing - Fix ERR_STREAM_DESTROYED errors in media processing - Improve stream lifecycle management 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>

purpshell · 2025-11-19T13:36:44Z

src/Socket/socket.ts

 		if (!creds.me) {
 			node = generateRegistrationNode(creds, config)
-			logger.info({ node }, 'not logged in, attempting registration...')
+			//logger.info({ node }, 'not logged in, attempting registration...')


Why are you commenting this

purpshell · 2025-11-19T13:36:49Z

src/Socket/socket.ts


 		closed = true
-		logger.info({ trace: error?.stack }, error ? 'connection errored' : 'connection closed')
+		//logger.info({ trace: error?.stack }, error ? 'connection errored' : 'connection closed')


purpshell · 2025-11-19T13:37:04Z

src/Socket/socket.ts

-	let didStartBuffer = false
 	process.nextTick(() => {
-		if (creds.me?.id) {
-			// start buffering important events
-			// if we're logged in
-			ev.buffer()
-			didStartBuffer = true
-		}
-


Why did you remove event buffering?

purpshell · 2025-11-19T13:37:11Z

src/Socket/socket.ts

-		if (didStartBuffer) {
-			ev.flush()
-			logger.trace('flushed events for initial buffer')
-		}


purpshell · 2025-11-19T13:37:30Z

src/Utils/auth-utils.ts

 export function makeCacheableSignalKeyStore(
 	store: SignalKeyStore,
 	logger?: ILogger,
+	prefix?: string,


Why do you need a prefix?

purpshell · 2025-11-19T13:37:32Z

src/Utils/auth-utils.ts


 	function getUniqueId(type: string, id: string) {
-		return `${type}.${id}`
+		return prefix ? `${prefix}-${type}.${id}` : `${type}.${id}`


purpshell · 2025-11-19T13:38:14Z

src/Utils/messages-media.ts

+		try { aes.destroy() } catch { }
+		try { hmac.destroy() } catch { }
+		try { sha256Plain.destroy() } catch { }
+		try { sha256Enc.destroy() } catch { }


That doesn't look very safe, we should know if any of these are erroring.

purpshell · 2025-11-19T13:38:27Z

src/Utils/process-message.ts

+				//logger?.info(
+				//	{
+				//		histNotification,
+				//		process,
+				//		id: message.key.id,
+				//		isLatest
+				//	},
+				//	'got history notification'
+				//)


…ets#1969 to latest Baileys Applied PRs: - WhiskeySockets#2067: libsignal wasm - WhiskeySockets#2057: emit setting events - WhiskeySockets#1969: improve retry logic Note: PRs WhiskeySockets#1991, WhiskeySockets#1981, WhiskeySockets#1906, WhiskeySockets#1892 have conflicts with latest Baileys version and were skipped. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>

This reverts commit 5dd2bf5.

# Conflicts: # src/Socket/messages-recv.ts

Arctic-beaver added 3 commits October 17, 2025 20:56

Fixed writing in stream after it was closed

9a9b2ce

Added async chunks for fileWriteStream

69a3400

Merge branch 'master' into fix/images-stream-writer-error

c7bfd63

Updating branch

Arctic-beaver added 4 commits November 6, 2025 13:38

Commented unnecessary logs

7011bb1

Commented hist notification

b1e788f

Disabled event buffer

55cd321

Added prefix for cache store

5dd2bf5

purpshell requested changes Nov 19, 2025

View reviewed changes

purpshell force-pushed the master branch from df95836 to 247c717 Compare November 19, 2025 14:35

Arctic-beaver added 4 commits November 20, 2025 16:25

Revert "Added prefix for cache store"

ab9af36

This reverts commit 5dd2bf5.

Merge branch 'master' into fix/images-stream-writer-error

d84ad04

Deleted first privacy token update

a8f38ea

Added logs to token update

7e0a089

purpshell force-pushed the master branch from bd1c658 to f46e8b1 Compare November 21, 2025 15:35

Arctic-beaver added 3 commits November 21, 2025 19:35

Merge branch 'master' into fix/images-stream-writer-error

cb7cafe

# Conflicts: # src/Socket/messages-recv.ts

DR-2564 Deleted logging

9291fe9

Added receiving messageId

46ee14c

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Fix/images stream writer error - ERR_STREAM_DESTROYED #1969

Fix/images stream writer error - ERR_STREAM_DESTROYED #1969

Arctic-beaver commented Oct 23, 2025

Uh oh!

whiskeysockets-bot commented Oct 23, 2025 •

edited

Loading

Uh oh!

purpshell Nov 19, 2025

Uh oh!

purpshell Nov 19, 2025

Uh oh!

purpshell Nov 19, 2025

Uh oh!

purpshell Nov 19, 2025

Uh oh!

purpshell Nov 19, 2025

Uh oh!

purpshell Nov 19, 2025

Uh oh!

purpshell Nov 19, 2025

Uh oh!

purpshell Nov 19, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Fix/images stream writer error - ERR_STREAM_DESTROYED #1969

Are you sure you want to change the base?

Fix/images stream writer error - ERR_STREAM_DESTROYED #1969

Conversation

Arctic-beaver commented Oct 23, 2025

Prevent unhandled stream errors on media upload - ERR_STREAM_DESTROYED error

Summary

Context / Symptoms

Root cause

What I changed (high level)

Why this fixes it

Load conditions where it used to fail

Risk & compatibility

Uh oh!

whiskeysockets-bot commented Oct 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ How to confirm it works

📦 To test this PR locally:

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

whiskeysockets-bot commented Oct 23, 2025 •

edited

Loading