Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#2,689 2 comentarios 2 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 8 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
postgresql, redis, typescript
Área
api, backend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
9.8k
Forks
7.3k
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de evolution-foundation/evolution-api

Todos los issues de evolution-foundation/evolution-api

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.