Baileys

This is a bug in Baileys (confirmed in 7.0.0-rc13/rc14 and master): downloadEncryptedContent in src/Utils/messages-media.ts (line ~652) pipes the undici response stream without attaching an 'error' listener. When the connection is cut mid-body, undici raises TypeError: terminated on the source stream — since .pipe() does not forward errors, this becomes a process-level uncaughtException, and the destination stream is never ended, so await downloadMediaMessage(msg, 'buffer') never resolves or rejects and for await iteration hangs forever.

**Fix (patch the library):** In src/Utils/messages-media.ts, change:

return fetched.pipe(output, { end: true })

fetched.on('error', err => output.destroy(err))
return fetched.pipe(output, { end: true })

**How to apply:** Since the fix is inside the npm package, use patch-package (or pnpm's pnpm patch) to persist the change: edit node_modules/baileys/lib/Utils/messages-media.js the same way, then run npx patch-package baileys. With this patch, the returned stream rejects with TypeError: terminated at the consumer, so your existing try/catch around downloadMediaMessage can catch the failure and retry instead of the process crashing or the message handler stalling silently.

**Defensive coding until patched upstream:** Wrap media downloads with your own timeout (e.g., Promise.race against a timer) since the unpatched stream can hang indefinitely, and add a process.on('uncaughtException') handler as a last resort to prevent the undici error from killing the process. The workaround has been verified in production on Baileys 7.0.0-rc14 with Node 24.

This happens because image uploads call refreshMediaConn(), which queries the socket while the WebSocket may still be in CONNECTING state (readyState=0), causing sendRawMessage to throw Boom('Connection Closed'). Text messages rarely hit this since they need only one round trip. Fix: wait for the socket to fully open before sending media:

await sock.waitForSocketOpen();
await sock.sendMessage(jid, { image, caption });

waitForSocketOpen() resolves once the socket is open, waits if still connecting, and throws if closed/closing. Verified on @whiskeysockets/baileys 6.7.24 — delivery succeeds consistently after adding the wait.

This bug affects @whiskeysockets/baileys@7.0.0-rc.14 and current master. extractCommunityMetadata() expects a <community> node, but WhatsApp can return a <group> node, so the non-null assertion fails and community.attrs throws.

Immediate workaround: call groupMetadata() with the same community JID. A community JID is a normal @g.us JID, and this returns the needed metadata, including community-related fields:

const meta = await sock.groupMetadata(communityJid)

For description updates, use the group equivalent:

await sock.groupUpdateDescription(communityJid, newDescription)

Permanent fix: update the community metadata parser to accept either response shape and throw a classified error when both are missing:

const community =
  getBinaryNodeChild(result, 'community') ??
  getBinaryNodeChild(result, 'group')

if (!community) {
  throw new Boom('community metadata response carried no <community> or <group> node', {
    data: result,
  })
}

The same incorrect assumption affects communityUpdateDescription() and communityGetInviteInfo(); communityFetchAllParticipating() may silently return {} for the same reason.

In Baileys 7.0.0-rc13/rc14, sendMessageAck reads authState.creds.me.id before login, but creds.me is only populated after pairing. Change the call in src/Socket/messages-recv.ts to use optional chaining:

- const stanza = buildAckStanza(node, errorCode, authState.creds.me.id);
+ const stanza = buildAckStanza(node, errorCode, authState.creds.me?.id);

buildAckStanza already handles a falsy meId; pre-login notification ACKs do not require the from attribute. Rebuild the package or use patch-package until the fix is released. This resolves the hidden TypeError and the misleading failed to ack notification { ackErr: {} } log. It does not by itself fix QR pairing or unhandled companion_reg_refresh notifications.

Before sending a 1:1 message to an @s.whatsapp.net PN JID, resolve it through Baileys' local LID mapping: call signalRepository.lidMapping.getLIDForPN(pn). If a LID is returned, send the message to <lid>@lid instead of the PN JID, and preserve the original PN as remoteJidAlt metadata. For example, route 19178056839@s.whatsapp.net to 148373990592755@lid when that mapping exists. This avoids the asynchronous messages.update rejection with messageStubParameters: ["463"] and should produce normal SERVER_ACK/DELIVERY_ACK responses. If no local LID mapping exists, keep the existing PN resolution path rather than forcing an implicit USync. Upstream fixes implement this PN-to-LID resolution in the send/relay path.