fix: report the missing message instead of failing a delivered send - #151
Open
DenysSamoiliuk wants to merge 2 commits into
Open
fix: report the missing message instead of failing a delivered send#151DenysSamoiliuk wants to merge 2 commits into
DenysSamoiliuk wants to merge 2 commits into
Conversation
Callers keep the id from the returned message to correlate it later, so a success response that carries no message leaves them dereferencing undefined - the failure surfaces in their code, far from its cause. whatsapp-web.js returns nothing when it refuses to send the content, an unsupported content type for a channel or a status, which is a failure and now reports as one on both the client and the channel endpoint. It also returns nothing when the message went out but the lookup that follows the send missed it, so the failure branch logs what the page looks like at that moment - whether a fresh MsgKey exposes `_serialized`, and how the keys of the messages already in the chat are shaped - which is what tells those two cases apart. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Answering 500 was the wrong call. `WWebJS.sendMessage` hands the message to
the chat and awaits it, and only then looks it up with
`Msg.get(newMsgKey._serialized)` - so a lookup that misses says nothing
about whether the contact got the message. On WhatsApp Web builds that
renamed `_serialized` it misses for every send, and a caller that retries
on 500 delivers a second copy of something the contact already has.
Answer 200 with an explicit `message: null` and a warning instead. The
caller still learns that it has no id to correlate on, which is what the
silent `{success: true}` failed to tell it, but nothing invites a retry.
`logMissingMessage` stays: it is what identified the cause, a page whose
`MsgKey` no longer exposes `_serialized`.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The problem
POST /client/sendMessagecan answer{"success": true}with nomessageat all. Callers keep the returned id to correlate the message later, so a success with nothing in it leaves them dereferencing undefined.Why this is not a 500
My first version of this PR answered 500. That was wrong, and worth spelling out.
window.WWebJS.sendMessagehands the message to the chat and awaits it, and only then looks it up —src/util/Injected/Utils.js:So a lookup that misses says nothing about whether the contact received the message. On WhatsApp Web 2.3000.x, which no longer exposes
_serializedonMsgKey, it misses on every send — and a caller that retries on 500 delivers a second copy of something the contact already has.What it does now
Answer 200 with an explicit
message: nulland a warning:{ "success": true, "message": null, "warning": "whatsapp-web.js did not return the sent message; it may still have been delivered" }The caller still learns it has no id to correlate on — which is what the silent
{"success": true}failed to tell it — but nothing invites a retry. Same treatment inchannelController.logMissingMessagestays. It reports what the page looked like at that moment — whether a freshMsgKeyexposes_serialized, and how the keys of the messages already in the chat are shaped. That is what identified the cause in the first place.Related
#150 removes the common cause: the
_serializedgetter it installs is what makes thatMsg.gethit, and it now survives page reloads. With that in, this path should be rare — but the response shape should still not lie either way.Testing