whatsapp-web.js compatibility: LID addressing, media and chat sync

In this release7

1. FixedMediaHigh impact

   Group media downloads fixed for LID participants

   Incoming media from a group failed with an opaque Puppeteer error whenever the participant was addressed as a LID. Upstream issue #201908 has the detail: a group message id carries four components, false_<group>@g.us_<message id>_<participant>@lid, and the download path was still assuming the three component form. Issue #201833 covers the same opaque failure on the general media path.

   What we changed:

   • The media resolver builds the full four component id, including the participant, before it asks for the media.
   • When a message exposes only the renamed key rather than _serialized, we fall back to the reconstructed id instead of giving up.
   • A failed download surfaces the message id and the chat it came from instead of the minified error, so support can actually act on it.
   • The download is retried once against a refreshed message handle, which clears the cases caused by a stale reference.

   Before

   Media from a group with LID participants failed with an opaque error and the attachment never reached the inbox.

   After

   The full four component message id is used, so group media downloads and is stored against the right contact.

2. FixedContactsHigh impact

   Contact and chat lookup works for LID only accounts

   getChatById returned "No LID for user" for every contact that WhatsApp now represents as a LID, described upstream in issue #201834. On our side that meant a contact could be imported and then never resolved to a chat, so the campaign quietly skipped it.

   What we changed:

   • We store both the phone number identity and the LID for a contact, and resolve in that order with a fallback, instead of assuming one form.
   • The contact sync backfills LIDs for existing contacts on the next successful chat fetch, so old lists heal on their own.
   • A contact that still cannot be resolved is reported as unreachable in the campaign report with the reason, instead of being counted as sent.
3. FixedContacts

   Chat sync no longer comes back empty on 2.3000 builds

   getChats returned an empty array on WhatsApp Web 2.3000.1041451627 and later, reported upstream as issue #201841. An empty sync looked identical to an account with no chats, so the dashboard showed nothing and the stored list was overwritten.

   What we changed:

   • The chat store is read through a version aware accessor that handles both the old and the new shape.
   • An empty result is treated as a suspicious result. We retry once, and if it is still empty we keep the previous list and flag the sync rather than wiping it.
   • A contact list is never replaced by an empty set from a failed sync, which is what was clearing lists before.
4. FixedMessaging

   Replies keep their quoted message on LID builds

   quotedMessageId needs a serialized LID message id rather than the plain message id the library documents, which is upstream issue #201855. Replies sent from automation flows were arriving as ordinary messages with no quote attached, so the recipient lost the context.

   What we changed:

   • The reply path serialises the quoted id in the form the current build expects, and falls back to the plain id on older builds.
   • Auto reply and flow steps that quote a trigger message keep the quote.
   • If the quoted message can no longer be found, the reply is still sent without the quote instead of failing the whole step.
5. FixedMessaging

   Reactions, unread marking, block and unblock no longer throw

   Three separate library errors were reaching our workers as unhandled failures:

   • Reaction message keys kept _serialized undefined on the renamed builds, upstream issue #201846.
   • Reading markedUnread threw "Cannot read properties of undefined", upstream issue #5718.
   • Contact.block and unblock threw on a missing block helper, upstream issue #201866.

   What we changed:

   • Each of these reads goes through a guarded accessor that returns a safe default rather than throwing into the worker.
   • Reaction events with an incomplete key are matched back to the original message by chat and timestamp.
   • Block and unblock use the current helper with a fallback to the older path, and report a clear error when neither is available.
   • None of these can take a worker down any more, so one odd message no longer stops a running campaign.
6. FixedSystem

   The passkey prompt no longer blocks startup authentication

   Some accounts hung during initialise because WhatsApp asked for passkey verification before the client could restore the session, which is upstream issue #201806. The process sat there with no error until it timed out, and the slot stayed occupied the whole time.

   What we changed:

   • The passkey prompt is detected during initialise and reported as its own state instead of a hang.
   • You get an actionable message in the dashboard telling you what to confirm on the phone.
   • Initialise has a hard deadline, so a blocked start fails fast and can be retried rather than holding a session slot.
7. ImprovedSystem

   QR pairing no longer times out after a successful scan

   A scan could be accepted on the phone while the client still reported a QR timeout, reported upstream as issue #5751, which sent people around the pairing loop a second time for no reason.

   What we changed:

   • The pairing window is extended once the scan is acknowledged, instead of being fixed from the moment the code is drawn.
   • The QR is refreshed in place rather than restarting the whole client, so a slow scan does not lose the attempt.
   • The pairing screen shows the stage it is at, from waiting for scan through to syncing.