[BUG] groupsIgnore=true drops group retry receipts, leaving some devices stuck on "Waiting for this message" #2783

Welcome!

• Yes, I have searched for similar issues on GitHub and found none.

What did you do?

We investigated outgoing group messages that remained stuck on “Waiting for this message” on some recipient devices.

The sending instance had:

• groupsIgnore: true
• syncFullHistory: false

We reproduced the issue through our application and directly through POST /message/sendText/{instance} using Postman.

The same message was readable on the sender’s iPhone, the recipient’s WhatsApp Web session in Chrome, and a separate Evolution instance linked to the recipient’s account. However, it remained unreadable in WhatsApp Business on the recipient’s Samsung phone.

We temporarily enabled LOG_BAILEYS=debug and inspected the installed code. When the Samsung requested recovery, the group retry receipt was acknowledged but ignored before the retry handler ran.

We then changed only groupsIgnore to false, preserving the other instance settings, and sent a new message to the same test group. The retry was processed and all tested devices could read the new message.

The initial decryption failure is intermittent: enabling groupsIgnore does not make every group message fail. The problem becomes visible when a recipient device needs recovery.

What did you expect?

An instance that sends messages to groups should process protocol receipts required to recover those outgoing messages, even when incoming group content is ignored.

If groupsIgnore intentionally disables all group protocol processing, its documentation and UI should clearly warn that this can prevent recovery of outgoing messages.

What did you observe instead of what you expected?

With groupsIgnore=true and syncFullHistory=false, the sender acknowledged the recipient’s retry receipt but skipped recovery processing. The affected phone remained on “Waiting for this message”, while linked devices could read the message.

After setting groupsIgnore=false, the diagnostic sequence changed to:

1. Retry request received.
2. Original message found in the retry cache.
3. Recovery executed and sender keys distributed.
4. New test message readable on all tested devices.

No QR re-pairing or source-code patch was needed for this configuration change to resolve the test case.

This identifies a blocked recovery path. We have not established the cause of the initial decryption failure.

Screenshots/Videos

No response

Which version of the API are you using?

2.3.7 — official Docker image evoapicloud/evolution-api:v2.3.7

What is your environment?

Linux

Other environment specifications

Deployment: Docker Compose
Baileys: 7.0.0-rc.9, verified inside the running container
Database: PostgreSQL 15
Cache: Redis 7

Sender: WhatsApp on iPhone
Affected recipient: WhatsApp Business on Samsung Android
Unaffected linked recipient client: WhatsApp Web in Chrome

Relevant sender instance settings before the change:
groupsIgnore=true
syncFullHistory=false
alwaysOnline=false
readMessages=false
readStatus=false

LOG_BAILEYS=debug was temporarily enabled for diagnosis and disabled afterward.

If applicable, paste the log output

No response

Additional Notes

Confirmed workaround:
Set groupsIgnore=false on the sending instance while preserving the other settings.

This also enables processing of incoming group events, so users should consider the effect on connected integrations.

In the installed Baileys package, handleReceipt contains this early return before retry processing:

if (shouldIgnoreJid(remoteJid) && remoteJid !== S_WHATSAPP_NET) {
    logger.debug({ remoteJid }, 'ignoring receipt from jid');
    await sendMessageAck(node);
    return;
}

The Evolution socket configuration maps groupsIgnore to shouldIgnoreJid for group JIDs, with an exception when syncFullHistory is enabled.

Earlier troubleshooting:

• Upgrading to 2.3.7 alone did not resolve the issue.
• Re-pairing temporarily restored delivery, but the issue returned days later.
• Restarting/recreating the container did not resolve the reproduced failure.
• Previously investigated messages were present in the sender’s database.
• After changing groupsIgnore=false, successful recovery used the retry cache.
• The false setting remained persisted after container recreation.

We did not implement application-level resending. The successful test used a new message, whose protocol recovery preserved its original message ID. We are not claiming that all older stuck messages recovered.

Suggested improvement:
Separate incoming group content filtering from receipt processing required for outgoing message recovery. Alternatively, clearly document this limitation and warn users who send to groups with groupsIgnore enabled.

Related: #2706. The symptoms overlap, but this report identifies a specific configuration-driven early return that blocks retry handling. We are not claiming that it explains every case in that issue.

Full production logs are omitted because they contain private data. The diagnostic observations are summarized above.