Summary
After re-pairing an instance, every message sent with a phone number as the
recipient ends in ERROR in MessageUpdate and is never delivered. The same
instance, at the same moment, delivers normally when the recipient is addressed
by LID. Before the re-pairing, the very same instance delivered fine to phone
numbers.
This is not a banned/limited number: sending manually from the WhatsApp app of
the sender phone to a fresh recipient works (see "What we ruled out").
Environment
|
|
| Image |
evoapicloud/evolution-api:v2.3.7 (built 2025-12-05) |
| Evolution |
2.3.7 |
| Baileys |
7.0.0-rc.9 |
| Database |
PostgreSQL (DATABASE_PROVIDER=postgresql) |
| Cache |
Redis, CACHE_REDIS_ENABLED=true, CACHE_REDIS_SAVE_INSTANCES=true |
| Instance settings |
syncFullHistory: false, groupsIgnore: true, rejectCall: true |
| Pairing |
QR code |
Steps to reproduce
- Pair an instance by QR.
- Send messages with
POST /message/sendText/{instance} using
{"number": "<E.164 digits>", "text": "..."}. They deliver.
- Log out and re-pair the same instance (any reason — we hit it after
recreating the container).
- Send again, same endpoint, same payload shape, to recipients that have never
messaged the sender.
Expected: delivery, as before the re-pairing.
Actual: the API returns 200 with status: PENDING and a key.id; the
message shows up in the manager; and MessageUpdate records ERROR. Nothing
arrives.
Evidence
Counting the whole instance history, split at the moment of the re-pairing.
Recipients are distinct people across many area codes; the "after" batch is a
single campaign of 46 messages.
|
address |
outcome |
count |
| before |
phone (@s.whatsapp.net) |
DELIVERY_ACK |
7 |
| before |
phone |
SERVER_ACK |
6 |
| before |
phone |
READ |
3 |
| before |
phone |
ERROR |
10 |
| before |
LID (@lid) |
DELIVERY_ACK + READ |
4 |
| after |
phone |
ERROR |
62 |
| after |
phone |
any success |
0 |
| after |
LID |
DELIVERY_ACK / READ / SERVER_ACK |
3 |
The LID sends in the "after" row were made minutes apart from failing phone
sends, on the same process, to the same person — one address works, the other
does not.
Two more observations that may help:
- Incoming messages from that same person arrive with
remoteJid as
<id>@lid, never as <phone>@s.whatsapp.net.
- A send that eventually delivered recorded
ERROR, ERROR, then
DELIVERY_ACK — a retry path exists and sometimes succeeds, but for
recipients with no prior conversation it never did.
What we ruled out
- Number health / spam restriction. Sending by hand, from the WhatsApp app
of the sender number to a recipient that never talked to it, delivers
normally. The account is fine.
- Credentials / connectivity.
connectionStatus is open, the API accepts
every request, and /chat/whatsappNumbers answers correctly for the same
numbers that fail to receive (exists: true).
- Disk / temp files. Host at 39% usage; container
/tmp clean.
- Recipient-specific issue. The failing batch spans 46 different recipients
in unrelated area codes.
Where we think it goes wrong
In baileys 7.0.0-rc.9, LIDMappingStore.getLIDsForPNs looks up the cache, then
keys.get('lid-mapping', …), and only then falls back to USync via
pnToLIDFunc. signalStorage.resolveLIDSignalAddress uses that mapping to pick
the Signal session address on loadSession/storeSession.
Our reading is that the mapping is lost with the re-pairing and is not rebuilt
for recipients that never messaged the instance, so encryption keeps using the
PN address and the server rejects it. We could not confirm this from logs
because LOG_BAILEYS=error hides the trace line
(No LID mapping found for PN user …; batch getting from USync), and raising it
requires a restart, which on a production instance costs another pairing.
Happy to run any diagnostic that helps — we have a reproducible environment and
the full Message/MessageUpdate history.
Impact
Any deployment using phone numbers as recipients — which is the documented and
natural way to use sendText — silently stops delivering after a re-pair. The
API keeps answering 200, so monitoring based on the HTTP response reports
success while nothing reaches anyone. In our case a campaign of 46 messages
reported "sent" and delivered zero.
Summary
After re-pairing an instance, every message sent with a phone number as the
recipient ends in
ERRORinMessageUpdateand is never delivered. The sameinstance, at the same moment, delivers normally when the recipient is addressed
by LID. Before the re-pairing, the very same instance delivered fine to phone
numbers.
This is not a banned/limited number: sending manually from the WhatsApp app of
the sender phone to a fresh recipient works (see "What we ruled out").
Environment
evoapicloud/evolution-api:v2.3.7(built 2025-12-05)DATABASE_PROVIDER=postgresql)CACHE_REDIS_ENABLED=true,CACHE_REDIS_SAVE_INSTANCES=truesyncFullHistory: false,groupsIgnore: true,rejectCall: trueSteps to reproduce
POST /message/sendText/{instance}using{"number": "<E.164 digits>", "text": "..."}. They deliver.recreating the container).
messaged the sender.
Expected: delivery, as before the re-pairing.
Actual: the API returns
200withstatus: PENDINGand akey.id; themessage shows up in the manager; and
MessageUpdaterecordsERROR. Nothingarrives.
Evidence
Counting the whole instance history, split at the moment of the re-pairing.
Recipients are distinct people across many area codes; the "after" batch is a
single campaign of 46 messages.
@s.whatsapp.net)@lid)The LID sends in the "after" row were made minutes apart from failing phone
sends, on the same process, to the same person — one address works, the other
does not.
Two more observations that may help:
remoteJidas<id>@lid, never as<phone>@s.whatsapp.net.ERROR,ERROR, thenDELIVERY_ACK— a retry path exists and sometimes succeeds, but forrecipients with no prior conversation it never did.
What we ruled out
of the sender number to a recipient that never talked to it, delivers
normally. The account is fine.
connectionStatusisopen, the API acceptsevery request, and
/chat/whatsappNumbersanswers correctly for the samenumbers that fail to receive (
exists: true)./tmpclean.in unrelated area codes.
Where we think it goes wrong
In baileys 7.0.0-rc.9,
LIDMappingStore.getLIDsForPNslooks up the cache, thenkeys.get('lid-mapping', …), and only then falls back to USync viapnToLIDFunc.signalStorage.resolveLIDSignalAddressuses that mapping to pickthe Signal session address on
loadSession/storeSession.Our reading is that the mapping is lost with the re-pairing and is not rebuilt
for recipients that never messaged the instance, so encryption keeps using the
PN address and the server rejects it. We could not confirm this from logs
because
LOG_BAILEYS=errorhides thetraceline(
No LID mapping found for PN user …; batch getting from USync), and raising itrequires a restart, which on a production instance costs another pairing.
Happy to run any diagnostic that helps — we have a reproducible environment and
the full
Message/MessageUpdatehistory.Impact
Any deployment using phone numbers as recipients — which is the documented and
natural way to use
sendText— silently stops delivering after a re-pair. TheAPI keeps answering
200, so monitoring based on the HTTP response reportssuccess while nothing reaches anyone. In our case a campaign of 46 messages
reported "sent" and delivered zero.