Baileys

これは Baileys のバグです（7.0.0-rc13/rc14 および master で確認済み）：src/Utils/messages-media.ts（652行目付近）にある downloadEncryptedContent は、'error' リスナーをアタッチしないまま undici のレスポンスストリームをパイプしています。接続がボディの途中で切断されると、undici はソースストリーム上で TypeError: terminated を送出します。.pipe() はエラーを転送しないため、これはプロセスレベルの uncaughtException となり、デスティネーションストリームは終了されません。その結果、await downloadMediaMessage(msg, 'buffer') は resolve も reject もされず、for await の反復が永遠にハングします。

**修正方法（ライブラリへのパッチ）：** src/Utils/messages-media.ts で、次のコードを：

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

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

**適用方法：** 修正箇所は npm パッケージの内部にあるため、patch-package（または pnpm の pnpm patch）を使って変更を永続化します。node_modules/baileys/lib/Utils/messages-media.js を同じように編集し、その後 npx patch-package baileys を実行します。このパッチを適用すると、返されるストリームはコンシューマー側で TypeError: terminated で reject されるようになるため、プロセスがクラッシュしたりメッセージハンドラーが警告なく停止したりする代わりに、downloadMediaMessage を囲む既存の try/catch で失敗をキャッチしてリトライできるようになります。

**上流で修正されるまでの防御的コーディング：** パッチ未適用のストリームは無期限にハングする可能性があるため、メディアのダウンロードを独自のタイムアウト（例：タイマーと競合させる Promise.race）でラップし、最後の手段として process.on('uncaughtException') ハンドラーを追加して、undici のエラーでプロセスが落ちるのを防いでください。この回避策は、Baileys 7.0.0-rc14 と Node 24 の環境で本番運用により検証済みです。

これは、画像のアップロード時に refreshMediaConn() が呼び出されることが原因で発生します。この関数は、WebSocket がまだ CONNECTING 状態（readyState=0）にある可能性があるタイミングでソケットにクエリを実行するため、sendRawMessage が Boom('Connection Closed') をスローします。テキストメッセージは1回のラウンドトリップで済むため、この問題が発生することはほとんどありません。修正方法：メディアを送信する前に、ソケットが完全に開くまで待機します：

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

waitForSocketOpen() は、ソケットが開いた時点で resolve され、まだ接続中の場合は待機し、closed/closing の場合はスローします。@whiskeysockets/baileys 6.7.24 で検証済みです — 待機を追加した後、送信は常に成功するようになりました。

このバグは @whiskeysockets/baileys@7.0.0-rc.14 と現在の master に影響します。extractCommunityMetadata() は <community> ノードを想定していますが、WhatsApp が <group> ノードを返すことがあるため、非 null アサーションが失敗し、community.attrs で例外がスローされます。

暫定的な回避策: 同じコミュニティ JID を指定して groupMetadata() を呼び出してください。コミュニティ JID は通常の @g.us JID であり、これによりコミュニティ関連フィールドを含む必要なメタデータが返されます:

const meta = await sock.groupMetadata(communityJid)

説明の更新には、グループ相当のメソッドを使用してください:

await sock.groupUpdateDescription(communityJid, newDescription)

恒久対策: コミュニティメタデータのパーサーを更新し、どちらのレスポンス形式も受け入れられるようにして、両方とも存在しない場合は分類されたエラーをスローするようにします:

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

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

同じ誤った前提が communityUpdateDescription() と communityGetInviteInfo() にも影響しています。communityFetchAllParticipating() も同じ理由で暗黙的に {} を返す可能性があります。

Baileys 7.0.0-rc13/rc14 では、sendMessageAck がログイン前に authState.creds.me.id を読み取りますが、creds.me はペアリング後にのみ設定されます。src/Socket/messages-recv.ts 内の呼び出しを、オプショナルチェーンを使用するように変更してください。

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

buildAckStanza は falsy な meId をすでに処理しており、ログイン前の notification ACK には from 属性は必要ありません。修正がリリースされるまでは、パッケージを再ビルドするか patch-package を使用してください。これにより、隠れていた TypeError と誤解を招く failed to ack notification { ackErr: {} } ログが解消されます。なお、これだけでは QR ペアリングや未処理の companion_reg_refresh 通知は修正されません。

@s.whatsapp.net の PN JID に 1:1 メッセージを送信する前に、Baileys のローカル LID マッピングを通じて解決してください。signalRepository.lidMapping.getLIDForPN(pn) を呼び出します。LID が返された場合は、PN JID の代わりに <lid>@lid にメッセージを送信し、元の PN を remoteJidAlt メタデータとして保持してください。たとえば、そのマッピングが存在する場合、19178056839@s.whatsapp.net を 148373990592755@lid にルーティングします。これにより、messageStubParameters: ["463"] を伴う非同期の messages.update 拒否を回避でき、通常の SERVER_ACK/DELIVERY_ACK 応答が得られるはずです。ローカルの LID マッピングが存在しない場合は、暗黙的な USync を強制するのではなく、既存の PN 解決パスを維持してください。上流の修正では、この PN から LID への解決が send/relay パスに実装されています。