🐞 [BUG] messages.upsert event not triggered under high message load

[ecatugy]

🐞 [BUG] messages.upsert event not triggered under high message load

Describe the bug
When the instance receives a high volume of incoming messages, the messages.upsert event occasionally stops being triggered for some clients. As a result, certain user flows cannot respond to those messages because the event is never fired. This happens sporadically across a few instances and seems correlated with high incoming message volume.
It’s not a hardware limitation the server has significantly more resources than required for normal operation.

To Reproduce

1. Create a new Baileys connection.
2. Start receiving a large number of incoming messages in a short period.
3. Observe that at some point, messages.upsert stops being emitted for certain messages.

Expected behavior
The messages.upsert event should always be triggered for every incoming message, regardless of message volume or load.

Environment (please complete the following information):

• Baileys version: 7.0.0-rc.5
• Server environment: Yes
• Multiple clients on the same IP: Sometimes
• Using proxy: No
• connectOptions:
  {
  markOnlineOnConnect: false,
  syncFullHistory: false,
  generateHighQualityLinkPreview: false,
  connectTimeoutMs: 5 * 60 * 1000,
  defaultQueryTimeoutMs: 5 * 60 * 1000
  }

Additional context
I skip specific message types in my message handler, as shown below:

// Skip processing group messages
if (
  m?.key?.remoteJid?.endsWith('@g.us') ||
  m?.key?.remoteJid?.endsWith('@broadcast') ||
  m?.key?.remoteJid?.endsWith('@newsletter') ||
  m?.key?.remoteJid === 'status@broadcast'
) {
  continue;
}

The skipped messages include:

• Group chat messages (@g.us)
• Broadcast messages (@broadcast)
• Newsletter messages (@newsletter)
• Status updates (status@broadcast)

Even with these filters, the issue still occurs occasionally when message throughput is high.

[Bloxoid123]

You can ignore messages from the socket.
If you ignore them from outside, they will continue to consume and saturate the groups...
You could try

shouldIgnoreJid: jid => isJidBroadcast(jid) || isJidNewsletter(jid) || isJidStatusBroadcast(jid) || isJidGroup(jid),

const sock = makeWASocket({
            auth: {
                creds: state.creds,
                keys: makeCacheableSignalKeyStore(state.keys, logger),
            },
            version,
            logger,
            ...
            shouldIgnoreJid: jid => isJidBroadcast(jid) || isJidNewsletter(jid) || isJidStatusBroadcast(jid) || isJidGroup(jid),
        })

[alessandropcostabr]

🔧 Complementary: Event Deduplication + Backpressure Strategy

Great suggestion above about shouldIgnoreJid — that filters at protocol level.

But there's another layer: if your message handler is slow (database writes, external API calls), even with filtering, the event queue builds up and eventually Baileys drops newer events to prevent memory overflow.

We Tested This in Production (6 accounts, 1000+ daily messages)

Our solution combines 3 strategies:

1️⃣ Filter at Protocol Level (as suggested)

shouldIgnoreJid: jid => 
  isJidBroadcast(jid) || 
  isJidNewsletter(jid) || 
  isJidStatusBroadcast(jid) || 
  isJidGroup(jid),

2️⃣ Add Idempotency Keys in Handler

const processedIds = new Set();

sock.ev.on('messages.upsert', async (update) => {
  for (const msg of update.messages) {
    const key = msg.key.id; // Unique per message
    
    if (processedIds.has(key)) {
      logger.debug('[DEDUP] skipping duplicate', { key });
      continue;
    }
    
    processedIds.add(key);
    
    // Your slow processing here
    await saveToDatabase(msg);
  }
});

// Cleanup to prevent memory leak
setInterval(() => processedIds.clear(), 3600000); // 1h

3️⃣ Monitor with Event Sniff

Enable diagnostic mode to catch dropped events:

BAILEYS_EVENT_SNIFF=1 npm start
# Monitor: tail -f /tmp/baileys-sniff.log | grep messages.upsert

Root Cause

When handler is slow → event queue backs up → Baileys drops events to protect memory.

Symptom: messages.upsert fires inconsistently under load even though messages exist.

Full Guide

See #2415 for complete event deduplication patterns.

We achieved 0% event loss in production with these 3 layers combined.

---

From LATE — production WhatsApp system running 6 accounts with load testing