Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#2,689 2 comentários 2 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 5 dias

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
45/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Pouca atividade
Stack de tecnologia
postgresql, redis, typescript
Domínio
api, backend

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
TypeScript
Estrelas
9.9k
Forks
7.4k
Nenhum PR com merge em 30d

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de evolution-foundation/evolution-api

Todas as issues de evolution-foundation/evolution-api

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.