سير عملي يعمل بشكل جيد، لكن عند محاولة إرسال الرسالة مرة أخرى إلى رقم المستقبل، يبقى حالة الرسالة معلقة (PENDING) والرسالة لا تصل. كيف يمكن حل هذه المشكلة؟ أستخدم n8n من خلال Cloudfy وأقوم بدمجه مع WhatsApp عبر Evolution API. لقد تحققت بالفعل من جميع مدخلات كل عقدة والمعلومات صحيحة. المشكلة فقط أنه لا يستطيع إرسال الرسالة. بطبيعة الحال، تحققت بالفعل من أنني لا أستخدم عنوان URL للاختبار وسير عملي منشور. في Evolution، الحالة لها نفس الاسم في عقدة الإخراج وهي أيضاً نشطة ومتصلة بـ WhatsApp.
(حدد العقد على لوحتك واستخدم اختصارات لوحة المفاتيح CMD+C/CTRL+C و CMD+V/CTRL+V لنسخ ولصق سير العمل.)
إصدار n8n: 2.30.4 قاعدة البيانات (الافتراضي: SQLite): إعداد n8n EXECUTIONS_PROCESS (الافتراضي: own, main): تشغيل n8n عبر (Docker, npm, n8n cloud, desktop app): نظام التشغيل: Windows 11
n8n
27 أغسطس 2026، 5:49م
2
مرحباً @Henrique_Weiss ، بينما تنتظر الرد، إليك بعض الأشياء التي قد تساعدك:
الموارد المقترحة
تم المطابقة تلقائياً مع سؤالك.
المستندات:
المنتدى:
@jan ، @edumats ، @Zelite - لقد ساعدتم في حل مشاكل مماثلة من قبل، هل يمكنكم إلقاء نظرة؟
اقترحت تلقائياً بواسطة بوت المجتمع الخاص بـ n8n. إنها نسخة تجريبية - يرجى مشاركة تعليقاتك هنا .
مرحبا @Henrique_Weiss ! أهلا وسهلا بك في مجتمع n8n!
أعتقد أن هذا ليس سير العمل الخاص بك، لذا توقف عن تدقيق العقد. رسالة 200 بحالة PENDING لا تتقدم هي خطأ في Evolution مفتوح مرتبط بنقل WhatsApp إلى عنونة @lid : لا يتم إعادة بناء تعيين الرقم إلى LID، والإرسال يستمر في استخدام عنوان @s.whatsapp.net العادي، والخادم يرفضه. MessageUpdate ينتقل إلى ERROR على الرغم من أن API أخبرك برسالة 200.
بما أنك ترد على رسالة واردة، فلديك بالفعل ما تحتاجه. أرسل إلى remoteJid الذي جاء في حمولة المشغل بدلاً من الرقم العادي، لأن نموذج @lid هو الذي لا يزال يوصل. تم الإبلاغ عنه في 2.3.7 و2.4.0، لا يزال مفتوحاً:
opened 05:26PM - 13 Aug 26 UTC
## Summary
After re-pairing an instance, **every** message sent with a phone nu… mber 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.
مرحباً @Henrique_Weiss
opened 12:36AM - 03 Jul 26 UTC
bug
### Welcome!
- [x] Yes, I have searched for similar issues on [GitHub](https://… github.com/EvolutionAPI/evolution-api/issues) and found none.
### What did you do?
### Describe the bug
Private messages are never delivered.
The API returns **201 Created**, but every private message remains permanently **PENDING**.
Group messages are delivered normally.
### Environment
* Evolution API: v2.3.7
* Railway
* PostgreSQL
* Redis
* WhatsApp Multi Device
### Steps to reproduce
1. Create a new instance.
2. Scan a new QR Code.
3. Wait until the instance is connected.
4. Send a message to a private contact.
5. The API returns 201 but the message stays PENDING forever.
### Expected behavior
The private message should be delivered.
### Actual behavior
* Private chats: ❌ Always PENDING
* Group chats: ✅ Working normally
* Receiving messages: ✅ Working normally
### Logs
```text
Sending message to xxxxxxxxx@s.whatsapp.net
status: 1
Update messages
status: 0
messageStubParameters: ["463"]
stream errored out
```
### Additional information
Already tested:
* New instance
* New QR Code
* Different private contacts
* Sending from Evolution UI
* Sending through `/message/sendText`
* n8n removed from the test
* Typebot removed from the test
The problem remains the same.
### What did you expect?
The issue only affects private chats.
What has already been verified:
* Fresh instance created from scratch.
* New QR Code scanned.
* WhatsApp connection established successfully.
* Receiving messages works correctly.
* Sending messages to groups works correctly.
* Sending messages to private contacts always remains in `PENDING`.
* The API returns HTTP `201 Created`.
* The logs show `Sending message...`, followed by `status: 0`, `messageStubParameters: ["463"]`, and sometimes `stream errored out`.
* The same behavior occurs when sending from the Evolution UI and through the `/message/sendText` endpoint.
* n8n and Typebot were removed from the tests, so they are not involved in the issue.
If any additional logs or debug information are required, I can provide them.
### What did you observe instead of what you expected?
When sending a message to any private WhatsApp contact, the Evolution API returns HTTP `201 Created`, but the message remains permanently in the `PENDING` state and is never delivered.
The logs show that Baileys attempts to send the message (`Sending message to...`), but the status changes to `0` and never progresses to a delivered state. In some cases, `stream errored out` also appears in the logs.
The same behavior occurs when sending from the Evolution UI and through the `/message/sendText` endpoint.
Receiving messages works correctly, and sending messages to WhatsApp groups also works correctly. The problem only affects private chats.
### Screenshots/Videos
_No response_
### Which version of the API are you using?
Evolution API: v2.3.7
Baileys: 2.3000.1042581539
### What is your environment?
Docker
### Other environment specifications
_No response_
### If applicable, paste the log output
_No response_
### Additional Notes
_No response_
شكراً على المساعدة. سأختبره في أقرب وقت ممكن
اتضح أن المشكلة كانت في إصدار Evolution API نفسه. اضطررت إلى الرجوع إلى الإصدار 2.3.3 وعملت كما يجب. على أي حال، شكراً جزيلاً على مساعدتك
مساء الخير هنريكي، كيف حالك؟
إذا قمت بالرجوع إلى إصدار أقدم، هل سأضطر إلى إعادة إنشاء جميع المثيلات؟ هل يمكنك إخباري؟ أسأل لأن هذه مثيلات تعمل بشكل جيد وخاصة بعملاء نشطين.
شكراً لك
ريكاردو، لم أضطر إلى إعادة صياغة أو تغيير أي شيء على الإطلاق في سير عملي أو البنية التحتية أو الخادم الخاص بي، وما إلى ذلك.
{“output”:"أفهم تماماً.
أنا أيضاً استخدمه في هذه المشاريع من خلال Cloudfy.
لا شيء. لقد عمل كما كان يجب أن يعمل.
شكراً يا أخي.
أحضانك الكبيرة
رمز 200 من Evolution يعني فقط أن الواجهة البرمجية قبلت الطلب؛ PENDING يعني أن WhatsApp لم تؤكد استقباله أبداً. الأسباب الشائعة، الأكثر احتمالاً أولاً:
Socket “open” لكنه معطل. حالة الاتصال في Evolution لا تتحقق من أن المجرى لا يزال نشطاً، لذلك تبدو النسخة متصلة بينما لا شيء يسلم. الاختبار: أرسل نفس النص إلى مجموعة من تلك النسخة وتحقق من شاشة الأجهزة المرتبطة على الهاتف. إذا كان معطلاً، أعد تشغيل النسخة وراقب ما إذا استمرت لعدة ساعات؛ إن لم تستمر، تحقق من ذاكرة الحاوية وما إذا كانت حاويتان تشتركان في نفس مخزن الجلسة.2. عنونة LID. منذ Baileys 7.x بعض المستقبلين يتم حلهم فقط عبر @lid؛ الإرسال إلى @s.whatsapp.net بعد إعادة إقران ينتهي به الحال في ERROR/PENDING (open: evolution-foundation/evolution-api#2689). جرب معرف LID للمستقبل الملتقط من MESSAGES_UPSERT.
Cloudfy تمتلك نسخة Evolution؛ أقل من 2.3.x الإصلاح من مسؤوليتهم في التسليم.Alternativa à Evolution API: gerenciada e sem VPS | Wafly
