Skip to content

fix(revoke): use protocolMessageKey for original message ID#201696

Open
Adi1231234 wants to merge 2 commits intowwebjs:mainfrom
Adi1231234:fix/revoke-use-protocolMessageKey
Open

fix(revoke): use protocolMessageKey for original message ID#201696
Adi1231234 wants to merge 2 commits intowwebjs:mainfrom
Adi1231234:fix/revoke-use-protocolMessageKey

Conversation

@Adi1231234
Copy link
Copy Markdown
Contributor

@Adi1231234 Adi1231234 commented Apr 6, 2026

Description

When a message is revoked (deleted for everyone), WWJS reports the wrong message ID. The old code used a last_message variable to cache the most recent message, then compared it when a revoke came in. This was unreliable because the IDs don't match after revoke, and a single variable can only track one message at a time.

WhatsApp stores the original message key on the revoked model as protocolMessageKey. This PR reads it directly instead of guessing from a cache.

Changes:

  • Read msg.protocolMessageKey to get the original ID
  • Create the message object with the original ID: new Message(this, { ...msg, id: originalKey })
  • Remove the last_message cache
  • Skip serialization for non-revoke type changes in the browser listener

Verified from WhatsApp's bundle source code that every revoke goes through a single code path that always sets protocolMessageKey to the original key. It's stored as a persistent property on the model, so it survives serialization.

Testing Summary

Test Details

Ran a version with verification logs in production across multiple accounts for 3 weeks. 500 revoke events analyzed - protocolMessageKey was present and correct in 100% of cases. No edge cases or failures observed.

Environment

  • Machine OS: Windows 11
  • Phone OS: Android 14
  • Library Version: 1.34.6
  • WhatsApp Web Version: 2.3000.1036713926
  • Browser Type and Version: Chromium 138.0.7204.251
  • Node Version: 22.20.0

Type of Change

  • Dependency change (package changes such as removals, upgrades, or additions)
  • Bug fix (non-breaking change that fixes an issue)
  • New feature (non-breaking change that adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Non-code change (documentation, README, etc.)

Checklist

  • My code follows the style guidelines of this project.
  • All new and existing tests pass (npm test).
  • Typings (e.g. index.d.ts) have been updated if necessary.
  • Usage examples (e.g. example.js) / documentation have been updated if applicable.

read the original message key directly from protocolMessageKey instead
of relying on the broken last_message cache that often failed to match.
@github-actions github-actions bot added the api changes API modifications label Apr 6, 2026
@Adi1231234
Copy link
Copy Markdown
Contributor Author

Hi @2hoch1, I've re-submitted with the proper PR template this time. Let me know if everything looks good now!

@BenyFilho BenyFilho added the waiting for testers Needs testing label Apr 6, 2026
@sofi-ans
Copy link
Copy Markdown

sofi-ans commented Apr 8, 2026

@Adi1231234 Thanks for this PR! I've been hitting this issue for a long time - I tested it recently and it works great.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

api changes API modifications waiting for testers Needs testing

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants