Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Messages addressed to `@s.whatsapp.net` never deliver after re-pairing (status ERROR), while `@lid` works

Open
  • Is something wrong?
#2,689 2 comments 2 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
postgresql, redis, typescript
Domain
api, backend

Research direction

Start with POST /message/sendText/{instance}, MessageUpdate handling, and the Baileys LIDMappingStore.getLIDsForPNs and signalStorage.resolveLIDSignalAddress paths described in the issue. Reproduce the phone-number and @lid comparison across a re-pair, then inspect the mapping and USync trace output. Done means phone-number sends deliver after re-pairing without ending in ERROR, with the existing LID behavior preserved.

Written by the indexing model from the issue text.

Description

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

  1. Pair an instance by QR.
  2. Send messages with POST /message/sendText/{instance} using
    {"number": "<E.164 digits>", "text": "..."}. They deliver.
  3. Log out and re-pair the same instance (any reason — we hit it after
    recreating the container).
  4. 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.

Dominant language
TypeScript
Stars
9.7k
Forks
7.3k
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from evolution-foundation/evolution-api

All issues in evolution-foundation/evolution-api

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.