github rmyndharis/OpenWA v0.4.6

latest releases: sdk/go/v0.2.0, php-sdk-v0.2.0, py-sdk-v0.2.0...
one month ago

A reliability, correctness, and dashboard release. Identity & engine: Baileys gains a persistent,
cross-session lid -> phone table (shared resolution that survives restarts) plus a new from message
filter, and its contact/chat listing ids are now engine-neutral (@c.us). Webhooks: message
reactions now also fire as a message.reaction webhook (previously WebSocket-only). Dashboard:
selectable appearance palettes with light/dark/system mode, and a redesigned Templates workspace.
Hardening: the LibreTranslate client pins its outbound connection, and Baileys group-participant
operations address participants in the engine wire dialect. Two consumer-visible notes: Baileys
contact/chat-list ids flip @s.whatsapp.net -> @c.us (whatsapp-web.js already used @c.us), and
webhooks subscribed with * now also receive message.reaction.

Added

  • Persistent, cross-session lid -> phone resolution + a from filter on message history. A new
    lid_mappings table (on the data connection) records the lid -> phone mappings WhatsApp pushes us
    (history sync, contacts) so resolution is shared across sessions and survives restarts, instead of
    living only in one Baileys session's in-memory map. GET /api/sessions/:sessionId/messages now accepts
    a from query param that resolves through this table: filtering by a phone returns not just messages
    stored as <phone>@c.us but also those whose sender was an unresolved <lid>@lid that has since
    resolved to that phone - closing a gap where a phone-based filter silently missed the same person's
    lid-addressed (e.g. group) messages. The table is populated at runtime from the lid<->phone pairs the
    Baileys engine observes (inbound message senderPn/participantPn, the chats.phoneNumberShare
    event, contacts, and history sync), so it fills continuously without re-auth. Internally these ids are
    now carried by a typed WaId value object; it is in-memory only and serializes to the exact same
    neutral string, so no webhook / WebSocket / REST response shape changes. (#374)

  • Webhook parity for message reactions (message.reaction). Reactions were broadcast over the
    WebSocket only; they are now also delivered as a message.reaction webhook with the same payload (the
    reaction plus the post-apply reactions snapshot) and are selectable in the dashboard event picker.
    Idempotency is salted per dispatch, so a re-reaction is a distinct delivery while retries dedupe.
    Consumer-visible: webhooks subscribed with * now also receive this event. (#380)

  • Dashboard appearance palettes + redesigned Templates workspace. A new Appearance menu switches
    light / dark / system mode and selectable accent palettes (persisted and applied across the UI). The
    Templates page is redesigned into a searchable workspace with a saved-template library, editor, live
    preview, and placeholder inputs. (#361)

  • BAILEYS_LOG_LEVEL (trace|debug|info|warn|error, silent by default) surfaces the Baileys library's
    own diagnostics; trace dumps the decoded WhatsApp wire frames to stdout (context "baileys-wire") for
    analysis. (#375)

Fixed

  • Baileys engine: contacts, chats and recent history now sync on connect. Baileys defaults
    shouldSyncHistoryMessage to () => !!syncFullHistory, so with syncFullHistory unset it silently
    disabled the entire initial sync - the address-book/app-state sync never ran, so no contacts, chat
    list, recent messages, or lid -> phone mappings ever arrived. The adapter now passes
    shouldSyncHistoryMessage: () => true, enabling the sync while keeping the full-archive download
    opt-in via BAILEYS_SYNC_FULL_HISTORY (WhatsApp sends the recent window + contact snapshot, not the
    entire message history). (#375)

  • Message history chatId filter now matches across dialects. A chat addressed as <phone>@c.us (the
    neutral list id) now also returns messages stored under <phone>@s.whatsapp.net (e.g. an outbound send
    addressed by a raw engine id), so the conversation view is no longer empty when the stored and queried
    dialects differ - the same resolution the from filter uses. (#375)

  • Baileys engine: contact and chat listing ids are now engine-neutral (@c.us). getContacts /
    getChats / getContactById previously returned the raw <phone>@s.whatsapp.net id (visible in the
    dashboard, and mismatched against the @c.us chatId stored on messages). They now emit the neutral
    @c.us dialect like the message payloads; the read-back paths (sendSeen / deleteChat / contact
    lookup) accept the neutral id and fold it back internally, so sending and marking-read still round-trip.
    Consumer-visible: Baileys contact/chat-list ids flip @s.whatsapp.net -> @c.us (whatsapp-web.js
    already used @c.us). (#374)

  • Hardened the LibreTranslate translation client against DNS rebinding. The client validated the
    target host and then issued a separate request that re-resolved DNS at connect time. It now pins the
    connection to the pre-validated address (the same SSRF-safe path webhook and media delivery use) and
    refuses redirects, so the API key (sent in the request body) cannot be redirected to an internal target
    between the host check and the connection. (#377)

  • Baileys group-participant operations now address participants in the engine wire dialect. Add /
    remove / promote / demote and group creation passed neutral <phone>@c.us participant ids straight to
    the wire, where they encode as an unknown server suffix instead of the s.whatsapp.net protocol token.
    They now fold to the engine dialect before the call (matching how 1:1 sends already round-trip); @lid
    and the @g.us group id are untouched, and the returned group info stays neutral @c.us. (#378)

  • Italian translation corrections. Updated and corrected the Italian (it) dashboard locale. (#376)

Don't miss a new OpenWA release

NewReleases is sending notifications on new releases.