Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#2,689 コメント 2 件 リアクション 2 件 担当者 0 名 GitHub で見る

メンテナーはふだん 5 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
45/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
静か
技術スタック
postgresql, redis, typescript
領域
api, backend

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
TypeScript
スター
9.8k
フォーク
7.3k
30日以内にマージされた PR はありません

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

evolution-foundation/evolution-api のほかの issue

evolution-foundation/evolution-api の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。