Repository navigation
chat.deleteMessage route doesnt really work #22
Description
Welcome!
- Yes, I have searched for similar issues on GitHub and found none.
What did you do?
used via n8n nodes in chat.deleteMessage with contact number as @lid as @s.whatsapp.net, and the message id, in group and in private.
What did you expect?
the message to be deleted
What did you observe instead of what you expected?
i recived 200 ok, and pending, but nothing has deleted.
Screenshots/Videos
No response
Which version of the API are you using?
last one
What is your environment?
Docker
Other environment specifications
No response
If applicable, paste the log output
No response
Additional Notes
i need you to check upstream and in baileys to see if it's there or somthing you can fix in this fork code
Activity
Neup123 commentedon Sep 19, 2026
Validated two concrete problems in the current delete path:
The prepared isolated-branch fix preserves the full original key, looks up the original deleted message ID, scopes the lookup to the current instance, and adds regression coverage for direct LID and group-participant keys. This does not prove WhatsApp deleted the remote message until tested against a connected instance, so the issue should remain open until that live check passes.
mainis untouched.fix(chat): preserve exact message keys
Neup123 commentedon Sep 21, 2026
The identified backend and n8n defects are fixed and released: deletion now carries the complete original message key and looks up the original deleted message ID within the current instance; n8n v4.3.0 exposes the corresponding fields. I am intentionally leaving this issue open because a real connected-WhatsApp remote deletion has not been performed during release review—doing that without an explicitly designated disposable message would be destructive. Please retest against v5.3.0 + n8n nodes v4.3.0 and report the resulting delete response/event.
Neup123 commentedon Sep 22, 2026
New v5.4.0 group/LID reproduction reported from n8n:
chat.deleteMessageremoteJid, original messageid, andparticipant: "...@lid"chabad-infoSource review confirms the remaining gap: the route forwards only the key fields supplied by the caller. For a group message, Baileys needs the exact original key, including the participant namespace metadata (
participantAltandaddressingMode) when WhatsApp supplied them. The archive/database already stores that complete original key, but the delete path does not hydrate omitted fields from it before calling Baileys. Preserving supplied fields is therefore insufficient for n8n callers that only haveparticipant: @lid+ message ID.I am preparing an isolated
instinct/group-delete-lidfix that resolves the stored original key by instance + message ID before sending the delete stanza, while keeping request validation and instance scoping. Main is untouched. Remote deletion still needs an explicitly designated disposable live message for destructive acceptance testing.Neup123 commentedon Sep 22, 2026
Fix pushed for review:
6bc65b0a5d9e61d69ae1b08e704de3a88890ef0dThe delete path now looks up the authoritative stored message key using current instance + original message ID + matching group/chat JID, then hydrates missing protocol fields before calling Baileys. This restores , , , and the original value when n8n supplies only the group JID, message ID, and an participant. The requested message ID is retained so hydration cannot redirect the deletion to another message.
Regression coverage reproduces the partial group/LID request and verifies the complete stored key is reconstructed. Passed: message-key test, ESLint, TypeScript, and diff checks. No merge or live destructive deletion was performed.
Neup123 commentedon Sep 22, 2026
Correction to the preceding comment: shell formatting removed five inline field names. The hydrated fields are
participantAlt,addressingMode,remoteJidAlt, and the originalfromMevalue; the partial n8n request includes an@lidparticipant. No code or validation result changed.Neup123 commentedon Sep 22, 2026
Released fix evidence:
e23fe130673318e5dc2796db5d981405fff009ccfeae32cfeaead06d3826d8a402aa9c7c0c5ef769)The feature branch was deleted after the true merge. No force-push or squash/rebase was used. A destructive live group deletion was not run; final remote acceptance still needs an explicitly designated disposable message on v5.4.1.
Neup123 commentedon Sep 22, 2026
Corrective implementation is now in PR #31, with the companion n8n change in Neup123/n8n-nodes-evolution-api#16. Live execution evidence showed the most recent test was an incoming direct message; WhatsApp cannot revoke another person's direct message for everyone. The new route auto-detects ownership from the archived original key, selects admin revoke for another participant's group message, validates admin permission when group metadata resolves it, and rejects impossible direct-message revokes clearly. It also waits for Baileys acknowledgement across direct and group event channels before changing local state or emitting MESSAGES_DELETE. The n8n node defaults to Auto Detect and treats bare PENDING as an error. This issue stays open until CI, merge, image publication, and a designated live group-message acceptance test are complete.
Neup123 commentedon Sep 22, 2026
v5.4.2 and n8n nodes v4.3.1 are now released. Reopening only for the final designated live WhatsApp group-message acceptance test; the code, CI, merge, and release work is complete. Please test a disposable group message with Message Ownership = Auto Detect. A successful node result must include serverAcknowledged: true and status SERVER_ACK or stronger.
Neup123 commentedon Sep 22, 2026
Live follow-up clarified the required behavior: automatic deletion must choose the strongest permitted scope. Incoming direct messages from another person cannot be revoked for everyone, so the automatic route/node must fall back to Baileys delete-for-me and report that scope explicitly. The existing deleteMessageForEveryone route will remain strict for API compatibility. Implementation will also carry the original timestamp required by Baileys app-state deletion and distinguish EVERYONE acknowledgement from ME app-state acceptance.
Neup123 commentedon Sep 22, 2026
Released in Evolution API v5.4.3 via #32.
The single existing Delete Message endpoint now chooses the maximum permitted scope automatically:
Responses now identify
scope,target,serverAcknowledged,appStatePatchAccepted, and anyfallbackReason.The GHCR image is published as both
ghcr.io/neup123/evolution-api:v5.4.3and:latest, with matching registry digests.Keeping this issue open until a disposable live message confirms the direct-message and group-admin paths after deployment.