[BUG] waiting for message - Decryption fails on second message after fresh session (iPhone Specific?)

[gandalfhv]

Describe the bug
I am experiencing a critical session handling bug with the latest version of Baileys (v6.7.19). The bug is 100% reproducible and causes the bot to fail to send replies after the first successful message exchange in a new session.

To Reproduce
Steps to reproduce the behavior:

1. Start with a completely clean session (delete the entire auth_info_baileys folder).
2. Start the bot and scan the new QR code to link a new device.
3. Send the first message from a user phone (specifically an iPhone) to the bot.
4. Result: The bot correctly receives and decrypts the message, processes it, and sends a reply. The reply is successfully received on the user's iPhone.
5. Send a second message from the same iPhone.

Expected behavior
The bot should receive the second message and successfully send a reply.

Actual Behavior:
The bot receives and processes the second message correctly. However, when it tries to send the reply, it fails.

• The console logs Closing stale open session for new outgoing prekey bundle and dumps the session data. The reply is never sent.
• On the user's iPhone, when they send a third message, the "Waiting for message..." placeholder appears, as the session is now completely broken.

Environment (please complete the following information):

• Server Ubuntu
• What do your connectOptions look like?

•    ``` const { version, isLatest } = await fetchLatestBaileysVersion()
   console.log(`using WA v${version.join('.')}, isLatest: ${isLatest}  `)
   const { state, saveCreds } = await useMultiFileAuthState(path.resolve(basicURI, "cache", "auth_info_baileys"));
   this.sock = makeWASocket({
       version,
       auth: state,
       printQRInTerminal: false,
       getMessage: this.cacheService.getMensajeAConfirmar.bind(this.cacheService),
       shouldSyncHistoryMessage: (_msg: any) => false,
       syncFullHistory: false,
   });```
  

• Do you have multiple clients on the same IP? NO
• Are you using a proxy? NO

Additional context

• This issue seems to be specific to client phones running iOS (iPhone). I have tested with Android clients and the conversation works correctly.
• The WhatsApp account being used for the bot is new (created last month). I have another bot with an older WhatsApp account that works correctly with the same iPhone client, which suggests the issue might be related to how new accounts handle sessions.
• The pattern is perfectly reproducible. Deleting the specific session-{jid}.json file for the iPhone contact allows the first message to work again, but the second reply always fails.
• This issue persists across multiple Baileys versions (I've tested about 3 up to v6.7.19)
  Here is the log snippet that appears when the bot tries to send the reply to the second message:

Closing session: SessionEntry {
   _chains: {
     BZrbvffEH2X49pr2WDqZDIt94RQOfkLBMtWIMSj99Wx8: { chainKey: [Object], chainType: 1, messageKeys: {} }
   },
   registrationId: 388033131,
   currentRatchet: {
     ephemeralKeyPair: {
       pubKey: <Buffer ...>,
       privKey: <Buffer ...>
     },
     ...
   },
   ...
}```

[gandalfhv]

Further analysis and a more precise hypothesis on the root cause.

After extensive testing, I'm almost certain the issue is a session identity mismatch that occurs when replying to a user with a @lid identifier.

For context, this is how my code is handling incoming messages to correctly identify the user's real phone number (senderPn), which is then used as the recipient JID for all replies:

let remoteJid = message.key.remoteJid;
console.log('remoteJid', remoteJid); // This logs the @lid address from iPhones

if (remoteJid.endsWith('@lid')) {
    if (message.key.senderPn) {
        // I use the real phone number for all subsequent logic and replies
        remoteJid = message.key.senderPn;
    } else {
        console.error('LID message received without senderPn, cannot process.');
        return;
    }
}
const userNumber = remoteJid; // This is now the @s.whatsapp.net address

Here is the exact lifecycle of the bug with this logic in place:

1. The first message arrives from an iPhone. The remoteJid is a @lid address. My code correctly extracts the senderPn (@s.whatsapp.net).
2. The bot sends a reply to the senderPn address. This works perfectly, because a new session is established from scratch using pre-keys.
3. A session file is created on the file system, correctly named after the senderPn (e.g., session-xxxxxxxx.0.json).
4. The second message arrives from the same @lid address. My code again correctly extracts the senderPn.
5. The bot attempts to send the second reply to the senderPn address.
6. This is where it fails. Baileys finds the session file for the senderPn, but the attempt to use it results in the Closing stale open session for new outgoing prekey bundle error.

My conclusion is that when the first session is created, the cryptographic state inside the session file is intrinsically linked to the original @lid identifier. However, the session file itself is saved under the key of the @s.whatsapp.net JID. When the bot tries to send the second message, it looks up the session by the JID, finds it, but the keys inside are not valid for sending a message to that JID, only to the original LID. This mismatch breaks the session.

I hope this detailed analysis helps pinpoint the issue.

[GustavoNovak]

Good morning @gandalfhv. Isn't that issue the same as #1739?

[gandalfhv]

Good morning @gandalfhv. Isn't that issue the same as #1739?

Thank you, I have tried the solution you propose in that issue and indeed for the messages to reach the end user they must be sent using xxxx@lid, this is because the session keys are saved for @lid and not for @s.whatsapp.net, as I was able to verify, unfortunately I do not have the Android phone to test if the messages disappear from the phone, but it is a lesser evil, thank you very much for your support and guidance