whatsapp_notifier 0.9.3 → 0.9.4

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 819dcc600d0048b4dfc4c8af3536b6fc72c370f369eab26b9535da151693527c
-  data.tar.gz: f471a271b9fe8b855c4125993bf0e83b305f27f4e7ca748d685e27c6f5741081
+  metadata.gz: 338f3e790a991a451717a73f0867344775fe2b3275f422686ef1cb0c7937b964
+  data.tar.gz: 5027b7672782506107e9edf3e1e27b0ea2294bcafc73f8097fb127e23754b9cd
 SHA512:
-  metadata.gz: b7333fa14a494d7bdb1365888087a8c42befe27401b01845bc2cd257a7f2fbf010cdfae1a7fe944cfc104d71add24ec8a92fccaef6c7771e6cc5dce80dbbba93
-  data.tar.gz: 483341fc7e694da4c720eb805dace1279db52bb90c1fa195e227b1ff849b566aa8bca9ed9a616a28ea7165de73c0955a1d1343da12085cb8d10663bd9a5af7a2
+  metadata.gz: 733fa2d201bbcfaaf4d56df17269fcab69cda02709fb4fe728d2ebc8d918960419bcabbe6441ee091f25b6fce1ed42092a4860e3552278e24096fd79e528c920
+  data.tar.gz: 28118d7946fb4efba76b0b4ba3cc9ca9269a3df26736a9470296e1524d8ab3e8bed6ccb749a3bed8ff33790a48b9ea133cc57f1fae73b79ad126689b3ab281eb

data/lib/generators/whatsapp_notifier/install_service_generator.rb

@@ -16,6 +16,7 @@ module WhatsAppNotifier
         inbound.ts
         init_gate.ts
         media.ts
+        message_id.ts
         metrics.ts
         send.ts
         sessions.ts

data/lib/whatsapp_notifier/services/web_automation/index.ts

@@ -33,7 +33,8 @@ import {
     mediaGetResponse,
     mediaDeleteResponse
 } from './media';
-import { sentMessageId, sendValidationError, fetchMedia, captionOptions } from './send';
+import { sentMessageId, sendValidationError, fetchMedia, captionOptions, isLidResolutionError } from './send';
+import { MESSAGE_MODEL_ID_PATCH, ensureSerializedId } from './message_id';
 
 const app = new Hono();
 const port = Number(process.env.PORT || 3001);
@@ -136,6 +137,12 @@ async function pushSessionEvent(userId: string, event: 'session_ready') {
 // webhook). The catch keeps a single bad message from killing the listener.
 async function captureInbound(userId: string, msg: any) {
     try {
+        // Second line of defence for the missing `id._serialized` (see
+        // message_id.ts): the page-side patch is the real fix, this rebuilds
+        // the id from whatever crossed the boundary. It has to happen BEFORE
+        // media resolution — downloadMedia reads `this.id._serialized` off
+        // this exact object.
+        ensureSerializedId(msg);
         await processInbound(userId, msg, {
             resolveMedia: resolveMediaForMessage,
             push: pushWebhook
@@ -224,7 +231,51 @@ function clearChromiumSingletonLocks(userId: string) {
 
 function isTransientSendError(error: unknown) {
     const message = error instanceof Error ? error.message : String(error);
-    return message.includes("getChat") || message.includes("Cannot read properties of undefined");
+    return message.includes("getChat") || message.includes("Cannot read properties of undefined") ||
+        // Retryable only because the retry loop resolves the LID between
+        // attempts (see warmLidMapping) — on its own this would spin five
+        // times on the same missing chat-table row.
+        isLidResolutionError(error);
+}
+
+// Install the in-page getMessageModel wrapper that restores `id._serialized`
+// (see message_id.ts for why WhatsApp stopped handing it over).
+//
+// Best effort by design: a session whose page is mid-navigation just keeps the
+// Node-side rebuild in captureInbound. Never rejects — the ready handler must
+// carry on to the backfill either way.
+async function installMessageIdPatch(userId: string, client: Client) {
+    try {
+        const page = (client as any).pupPage;
+        if (!page) return 'no-page';
+        const result = await page.evaluate(MESSAGE_MODEL_ID_PATCH);
+        console.log(`Message-id patch for User ${userId}: ${result}`);
+        return result;
+    } catch (e) {
+        console.error(`Message-id patch failed for ${userId}`, e);
+        return 'failed';
+    }
+}
+
+// Make WhatsApp resolve the recipient's LID, after a send has already failed
+// for the want of it.
+//
+// getContactLidAndPhone runs WhatsApp's own queryWidExists for the number,
+// which is what writes the LID row the send path then reads. Without it a
+// first-contact chat (or one WhatsApp has since re-keyed) fails inside the
+// WhatsApp bundle with "Lid is missing in chat table" / "No LID for user" —
+// around a quarter of production sends at the time of writing.
+//
+// Best effort: the send is retried regardless, so a resolver hiccup can never
+// turn a deliverable message into a hard failure.
+async function warmLidMapping(client: Client, chatId: string) {
+    try {
+        const resolver = (client as any).getContactLidAndPhone;
+        if (typeof resolver !== 'function') return;
+        await resolver.call(client, [chatId]);
+    } catch (e) {
+        console.error(`LID warm-up failed for ${chatId}`, e);
+    }
 }
 
 async function waitForClientReady(clientData: ClientData, timeoutMs = 30000): Promise<void> {
@@ -245,6 +296,10 @@ async function sendMessageWithRetry(client: Client, clientData: ClientData, chat
 
     // Wait for the internal WWeb store to be fully loaded before first attempt
     await waitForClientReady(clientData);
+    // The LID warm-up is deliberately NOT run up front: most recipients
+    // already have their chat-table row and would only pay an extra WhatsApp
+    // query for it — a real cost on a 500-recipient broadcast. The retry loop
+    // warms only the recipients that actually fail (see warmLidMapping).
 
     for (let attempt = 1; attempt <= maxAttempts; attempt += 1) {
         try {
@@ -263,6 +318,10 @@ async function sendMessageWithRetry(client: Client, clientData: ClientData, chat
                 throw error;
             }
 
+            // A LID failure is not a hydration problem — the mapping is simply
+            // absent, so re-run the resolver before spending the next attempt.
+            if (isLidResolutionError(error)) await warmLidMapping(client, chatId);
+
             // Wait longer between retries to give the store time to hydrate
             await new Promise((resolve) => setTimeout(resolve, attempt * 3000));
         }
@@ -344,11 +403,23 @@ async function getOrCreateClient(userId: string): Promise<ClientData> {
         clearReadyTimer(clientData);
         initRetries.reset(userId);
         console.log(`Client is READY for User ${userId}`);
+        // Re-arm the message-id repair on EVERY ready: whatsapp-web.js
+        // re-injects its own window.WWebJS on each page load, which drops our
+        // wrapper, and 'ready' is the one event that fires again after a
+        // reload. Must run before the backfill below, so replayed messages
+        // carry real ids too.
+        const patched = installMessageIdPatch(userId, client);
         // Wake the host NOW — a campaign parked on "session down" should not
         // wait out a polling interval when the session just came back.
         pushSessionEvent(userId, 'session_ready').catch(console.error);
-        // Replay anything that arrived while we were disconnected.
-        backfillInbound(userId, client).catch((e) => console.error(`Backfill failed for ${userId}`, e));
+        // Replay anything that arrived while we were disconnected — after the
+        // patch, so replayed messages carry real ids and their media can be
+        // fetched. A failed patch must not cancel the backfill: the Node-side
+        // rebuild in captureInbound still applies.
+        patched
+            .catch(() => undefined)
+            .then(() => backfillInbound(userId, client))
+            .catch((e) => console.error(`Backfill failed for ${userId}`, e));
     });
 
     // Capture BOTH directions of every 1:1 chat. Only 'message_create' — it
@@ -621,6 +692,9 @@ app.post('/send/:userId', async (c) => {
         data.lastUsed = Date.now();
         // messageId is the echo-dedupe key: this send fires its own fromMe
         // message_create, which the host must match by id (see send.ts).
+        // Repaired first for the same reason as capture — an id-less send
+        // response means the echo comes back as a duplicate operator bubble.
+        ensureSerializedId(sent);
         const messageId = sentMessageId(sent);
         // Register the id so the echo is suppressed service-side (no media
         // re-download, no queue slot, no webhook — see inbound.ts). Best

data/lib/whatsapp_notifier/services/web_automation/message_id.test.ts

@@ -0,0 +1,157 @@
+import { test, expect } from 'bun:test';
+import { buildSerializedId, ensureSerializedId, MESSAGE_MODEL_ID_PATCH } from './message_id';
+
+// ── buildSerializedId ──
+//
+// The format is WhatsApp's own, and whatsapp-web.js parses it back apart in
+// Client#getMessageById: `fromMe_remote_id`, plus `_participant` when there
+// is one.
+test('buildSerializedId rebuilds the three-part id', () => {
+    expect(buildSerializedId({ fromMe: false, remote: '919999000001@c.us', id: 'ABC123' }))
+        .toBe('false_919999000001@c.us_ABC123');
+    expect(buildSerializedId({ fromMe: true, remote: '919999000001@c.us', id: 'ABC123' }))
+        .toBe('true_919999000001@c.us_ABC123');
+});
+
+test('buildSerializedId appends the participant as a fourth part', () => {
+    expect(buildSerializedId({
+        fromMe: false, remote: '12036@g.us', id: 'ABC123', participant: '919999000001@c.us'
+    })).toBe('false_12036@g.us_ABC123_919999000001@c.us');
+});
+
+// getMessageModel flattens `remote` to a string, but a Wid object still
+// reaches us in other shapes (and participant is never flattened) — accept
+// both rather than silently producing "[object Object]" in an id.
+test('buildSerializedId accepts Wid objects for remote and participant', () => {
+    expect(buildSerializedId({
+        fromMe: false,
+        remote: { _serialized: '919999000001@c.us' },
+        id: 'ABC123',
+        participant: { _serialized: '919999000002@c.us' }
+    })).toBe('false_919999000001@c.us_ABC123_919999000002@c.us');
+});
+
+// A partial id is worse than none: it looks real, gets accepted as a lookup
+// key, and resolves to nothing.
+test('buildSerializedId returns null when a required part is missing', () => {
+    expect(buildSerializedId(null)).toBeNull();
+    expect(buildSerializedId(undefined)).toBeNull();
+    expect(buildSerializedId({})).toBeNull();
+    expect(buildSerializedId({ fromMe: false, id: 'ABC123' })).toBeNull();            // no remote
+    expect(buildSerializedId({ fromMe: false, remote: '919999000001@c.us' })).toBeNull(); // no id
+    expect(buildSerializedId({ fromMe: false, remote: {}, id: 'ABC' })).toBeNull();   // unusable Wid
+    expect(buildSerializedId({ fromMe: false, remote: '919999000001@c.us', id: '' })).toBeNull();
+});
+
+// ── ensureSerializedId ──
+//
+// It MUTATES the message: whatsapp-web.js reads `this.id._serialized` off the
+// very object we hold (Message#downloadMedia passes it into the page), so
+// repairing a copy would fix our own bookkeeping and leave media broken.
+test('ensureSerializedId writes the rebuilt id back onto the message', () => {
+    const msg: any = { id: { fromMe: false, remote: '919999000001@c.us', id: 'ABC123' } };
+
+    expect(ensureSerializedId(msg)).toBe('false_919999000001@c.us_ABC123');
+    expect(msg.id._serialized).toBe('false_919999000001@c.us_ABC123');
+});
+
+// The day WhatsApp hands the property back, this must not overwrite it with a
+// reconstruction.
+test('ensureSerializedId leaves an existing id untouched', () => {
+    const msg: any = { id: { fromMe: false, remote: '919999000001@c.us', id: 'ABC', _serialized: 'REAL' } };
+
+    expect(ensureSerializedId(msg)).toBe('REAL');
+    expect(msg.id._serialized).toBe('REAL');
+});
+
+// Capture must survive a malformed message — never throw, never invent.
+test('ensureSerializedId reports null for an unrepairable message', () => {
+    expect(ensureSerializedId(null)).toBeNull();
+    expect(ensureSerializedId(undefined)).toBeNull();
+    expect(ensureSerializedId({})).toBeNull();
+
+    const msg: any = { id: { fromMe: false } };
+    expect(ensureSerializedId(msg)).toBeNull();
+    expect(msg.id._serialized).toBeUndefined();
+});
+
+// ── the page-side patch ──
+//
+// Exercised the way the page runs it: eval the source against a fake window
+// carrying a stand-in WWebJS. This is the primary fix (it runs where the
+// accessor still works), so its branches are worth covering directly.
+function runPatch(win: any): string {
+    const globalAny = globalThis as any;
+    const previous = globalAny.window;
+    globalAny.window = win;
+    try {
+        return (0, eval)(MESSAGE_MODEL_ID_PATCH);
+    } finally {
+        if (previous === undefined) delete globalAny.window;
+        else globalAny.window = previous;
+    }
+}
+
+// A live MsgKey still answers `_serialized` in-page — take it straight from
+// there rather than reconstructing.
+test('the patch fills _serialized from the live key', () => {
+    const win: any = { WWebJS: { getMessageModel: (m: any) => ({ id: { ...m.id, _serialized: undefined } }) } };
+
+    expect(runPatch(win)).toBe('patched');
+
+    const model = win.WWebJS.getMessageModel({
+        id: { fromMe: false, remote: '919999000001@c.us', id: 'ABC', _serialized: 'false_919999000001@c.us_ABC' }
+    });
+    expect(model.id._serialized).toBe('false_919999000001@c.us_ABC');
+});
+
+// toString() on a MsgKey yields the serialized id; on a plain object it yields
+// "[object Object]", which would pass a truthiness check and poison every id
+// written from it — so that shape must fall through to the manual rebuild.
+test('the patch ignores a "[object Object]" toString and rebuilds from parts', () => {
+    const win: any = { WWebJS: { getMessageModel: (m: any) => ({ id: { ...m.id } }) } };
+    runPatch(win);
+
+    const model = win.WWebJS.getMessageModel({
+        id: { fromMe: true, remote: { _serialized: '919999000001@c.us' }, id: 'XYZ' }
+    });
+    expect(model.id._serialized).toBe('true_919999000001@c.us_XYZ');
+});
+
+test('the patch uses a MsgKey toString when there is no accessor', () => {
+    const win: any = { WWebJS: { getMessageModel: (m: any) => ({ id: { fromMe: m.id.fromMe } }) } };
+    runPatch(win);
+
+    const key = { fromMe: false, toString: () => 'false_919999000001@c.us_TSTR' };
+    expect(win.WWebJS.getMessageModel({ id: key }).id._serialized).toBe('false_919999000001@c.us_TSTR');
+});
+
+// A model without its id still carries the message; the repair must never be
+// what breaks capture.
+test('the patch leaves an unrepairable model alone and never throws', () => {
+    const win: any = { WWebJS: { getMessageModel: () => ({ id: { fromMe: false } }) } };
+    runPatch(win);
+
+    expect(win.WWebJS.getMessageModel({ id: { fromMe: false } }).id._serialized).toBeUndefined();
+    expect(win.WWebJS.getMessageModel({}).id._serialized).toBeUndefined();
+    expect(win.WWebJS.getMessageModel({ id: null }).id._serialized).toBeUndefined();
+});
+
+test('the patch preserves an already-serialized model id', () => {
+    const win: any = { WWebJS: { getMessageModel: () => ({ id: { _serialized: 'REAL' } }) } };
+    runPatch(win);
+
+    expect(win.WWebJS.getMessageModel({ id: {} }).id._serialized).toBe('REAL');
+});
+
+// Re-armed on every 'ready', so double application has to be free — wrapping
+// the wrapper would re-run the repair for no gain.
+test('the patch is idempotent and reports when it cannot install', () => {
+    const win: any = { WWebJS: { getMessageModel: (m: any) => ({ id: { ...m.id } }) } };
+
+    expect(runPatch(win)).toBe('patched');
+    expect(runPatch(win)).toBe('already-patched');
+
+    expect(runPatch({})).toBe('no-store');
+    expect(runPatch({ WWebJS: {} })).toBe('no-store');
+});

data/lib/whatsapp_notifier/services/web_automation/message_id.ts

@@ -0,0 +1,146 @@
+// Repairs the serialized WhatsApp message id, which current WhatsApp Web no
+// longer hands across the puppeteer boundary.
+//
+// Every message model whatsapp-web.js emits is produced in-page by
+// window.WWebJS.getMessageModel(msg) and then JSON-serialized on its way out
+// (the Msg 'add' hook calls window.onAddMessageEvent, a page binding; bindings
+// and page.evaluate both marshal by JSON). JSON only copies OWN ENUMERABLE
+// properties, so a value that WhatsApp exposes as a prototype accessor is
+// silently dropped. MsgKey._serialized is now exactly that: readable in-page,
+// absent by the time the model reaches Node.
+//
+// The damage is not cosmetic — `id._serialized` is the message's only handle:
+//   * Message#downloadMedia passes it into the page (Msg.get(msgId) →
+//     Msg.getMessagesById([msgId])); with `undefined` the lookup throws, so
+//     EVERY media message resolves "download_failed" and the host renders a
+//     permanent "Media unavailable" bubble.
+//   * normalizeInbound falls back to `${counterparty}-${timestamp}`, which is
+//     not the id the host stored for its own /send, so the fromMe echo of our
+//     own send can no longer be deduped — and two messages in the same second
+//     on one chat collide onto a single fallback id.
+//
+// Two layers, because a page-side patch can be lost (a reload re-injects
+// whatsapp-web.js's own WWebJS) and a Node-side rebuild depends on parts that
+// may themselves stop crossing the boundary:
+//   1. MESSAGE_MODEL_ID_PATCH — wraps getMessageModel IN THE PAGE, where the
+//      accessor still works. Every emitted model gains a real, own
+//      `_serialized` before it is marshalled. This is the primary fix.
+//   2. ensureSerializedId — Node-side rebuild from the surviving key parts,
+//      applied to each captured message. Covers the window before the patch
+//      lands and any session where the patch could not be installed.
+
+// The key as it survives the boundary. Everything is optional on purpose:
+// this type describes damaged input, not the ideal shape.
+export type MessageKey = {
+    fromMe?: boolean;
+    remote?: unknown;
+    id?: string;
+    participant?: unknown;
+    _serialized?: string;
+};
+
+// WhatsApp's own serialization format, confirmed by whatsapp-web.js's parser
+// in Client#getMessageById: 3 parts, or 4 when the message carries a
+// participant (`fromMe_remote_id[_participant]`).
+//
+// Returns null unless every REQUIRED part is present — a partial id would be
+// worse than none: it would look real, be accepted as a lookup key, and
+// resolve to nothing.
+export function buildSerializedId(key: MessageKey | null | undefined): string | null {
+    if (!key) return null;
+    const remote = widString(key.remote);
+    const id = typeof key.id === 'string' ? key.id : '';
+    if (!remote || !id) return null;
+
+    const participant = widString(key.participant);
+    const head = `${key.fromMe ? 'true' : 'false'}_${remote}_${id}`;
+    return participant ? `${head}_${participant}` : head;
+}
+
+// `remote` and `participant` are Wid objects in-page. getMessageModel already
+// flattens `remote` to its string form, but participant gets no such
+// treatment, and a Wid that DID survive as an object still carries
+// `_serialized` — so accept either shape.
+function widString(wid: unknown): string {
+    if (typeof wid === 'string') return wid;
+    if (wid && typeof wid === 'object') {
+        const serialized = (wid as { _serialized?: unknown })._serialized;
+        if (typeof serialized === 'string') return serialized;
+    }
+    return '';
+}
+
+// Give one captured message a usable `id._serialized`, mutating it in place —
+// whatsapp-web.js reads `this.id._serialized` off the very object we hold, so
+// repairing a copy would fix our own bookkeeping and leave downloadMedia
+// broken.
+//
+// Returns the serialized id (existing or rebuilt), or null when the key is too
+// damaged to rebuild. Never throws: a capture path must not die on a malformed
+// message.
+export function ensureSerializedId(msg: { id?: MessageKey } | null | undefined): string | null {
+    const key = msg && msg.id;
+    if (!key) return null;
+    if (typeof key._serialized === 'string' && key._serialized) return key._serialized;
+
+    const rebuilt = buildSerializedId(key);
+    if (rebuilt) key._serialized = rebuilt;
+    return rebuilt;
+}
+
+// The page-side patch, as source to hand to page.evaluate.
+//
+// Idempotent (a flag on window), and it never replaces a working
+// `_serialized` — the day WhatsApp puts the property back, this becomes a
+// no-op wrapper instead of a competing implementation.
+//
+// In-page the accessor is readable, so the id is taken straight from the live
+// MsgKey; the manual rebuild is only the last resort, and mirrors
+// buildSerializedId above.
+//
+// Returns a short status string so the caller can log which happened.
+export const MESSAGE_MODEL_ID_PATCH = `(() => {
+    if (typeof window === 'undefined' || !window.WWebJS) return 'no-store';
+    if (window.__waMessageIdPatch) return 'already-patched';
+    const original = window.WWebJS.getMessageModel;
+    if (typeof original !== 'function') return 'no-store';
+
+    const widString = (wid) => {
+        if (typeof wid === 'string') return wid;
+        if (wid && typeof wid === 'object' && typeof wid._serialized === 'string') return wid._serialized;
+        return '';
+    };
+
+    window.WWebJS.getMessageModel = function (message) {
+        const model = original.apply(this, arguments);
+        try {
+            if (model && model.id && !model.id._serialized) {
+                const key = message && message.id;
+                let serialized = key && typeof key._serialized === 'string' ? key._serialized : '';
+                if (!serialized && key && typeof key.toString === 'function') {
+                    const asString = key.toString();
+                    // toString() on a plain object yields "[object Object]" —
+                    // a value that would pass a truthiness check and poison
+                    // every id it is written to.
+                    if (asString && asString.indexOf('[object') !== 0) serialized = asString;
+                }
+                if (!serialized && key) {
+                    const remote = widString(key.remote);
+                    const participant = widString(key.participant);
+                    if (remote && typeof key.id === 'string' && key.id) {
+                        serialized = (key.fromMe ? 'true' : 'false') + '_' + remote + '_' + key.id;
+                        if (participant) serialized += '_' + participant;
+                    }
+                }
+                if (serialized) model.id = Object.assign({}, model.id, { _serialized: serialized });
+            }
+        } catch (e) {
+            // A model without its id still carries the message; never let the
+            // repair itself break capture.
+        }
+        return model;
+    };
+
+    window.__waMessageIdPatch = true;
+    return 'patched';
+})()`;

data/lib/whatsapp_notifier/services/web_automation/send.test.ts

@@ -1,5 +1,5 @@
 import { test, expect } from 'bun:test';
-import { sentMessageId, sendValidationError, fetchMedia, captionOptions } from './send';
+import { sentMessageId, sendValidationError, fetchMedia, captionOptions, isLidResolutionError } from './send';
 
 // The id the host stores against its outbound record — it MUST be the real
 // serialized WhatsApp id so the fromMe echo of this send dedupes on it.
@@ -76,3 +76,23 @@ test('captionOptions omits the caption entirely for caption-less files', () => {
     expect(captionOptions(undefined)).toEqual({});
     expect(captionOptions(null)).toEqual({});
 });
+
+// ── LID resolution failures ──
+//
+// These are WhatsApp's OWN assertion texts, thrown inside its bundle when the
+// chat table has no LID row for the recipient. There is no error code to key
+// on — the text is the whole signal — and the stack tail WhatsApp appends
+// (its minified bundle URL) must not stop the match.
+test('isLidResolutionError recognises both WhatsApp LID assertions', () => {
+    expect(isLidResolutionError(new Error('Lid is missing in chat table\ns (https://static.whatsapp.net/rsrc.php/v4/y3/r/QOqeh94VsFD.js:84:180)')))
+        .toBe(true);
+    expect(isLidResolutionError(new Error('No LID for user\ns (https://static.whatsapp.net/rsrc.php/v4/y3/r/QOqeh94VsFD.js:84:180)')))
+        .toBe(true);
+    expect(isLidResolutionError('No LID for user')).toBe(true); // thrown as a bare string
+});
+
+test('isLidResolutionError leaves unrelated send failures alone', () => {
+    expect(isLidResolutionError(new Error('Evaluation failed: TypeError'))).toBe(false);
+    expect(isLidResolutionError(new Error('User not authenticated'))).toBe(false);
+    expect(isLidResolutionError(undefined)).toBe(false);
+});

data/lib/whatsapp_notifier/services/web_automation/send.ts

@@ -50,6 +50,21 @@ export async function fetchMedia(messageMedia: MediaFactory, mediaUrl: string) {
     return messageMedia.fromUrl(mediaUrl, { unsafeMime: true });
 }
 
+// WhatsApp Web addresses chats by LID now, and resolves the LID for a plain
+// phone jid out of its own chat table. When that row is missing the send dies
+// inside WhatsApp's own bundle with one of these — WhatsApp assertion texts,
+// not whatsapp-web.js errors, so there is nothing to match on but the text:
+//   "Lid is missing in chat table"  — 1:1 send, chat row has no LID
+//   "No LID for user"               — recipient never resolved at all
+//
+// The row is populated by asking WhatsApp whether the number exists
+// (queryWidExists, reached through Client#getContactLidAndPhone), which is why
+// the warm-then-retry in index.ts clears both.
+export function isLidResolutionError(error: unknown): boolean {
+    const message = error instanceof Error ? error.message : String(error);
+    return message.includes('Lid is missing in chat table') || message.includes('No LID for user');
+}
+
 // sendMessage options for a media send: caption only when there IS one. A
 // caption-less file arrives with message "" — omitting the key entirely
 // matches a hand-sent file instead of attaching an empty caption.

data/lib/whatsapp_notifier/version.rb

@@ -1,4 +1,4 @@
 module WhatsAppNotifier
-  VERSION = "0.9.3"
+  VERSION = "0.9.4"
 
 end

data/spec/generators/install_service_generator_spec.rb

@@ -58,7 +58,8 @@ RSpec.describe "WhatsAppNotifier::Generators::InstallServiceGenerator" do
       generator.copy_service_files
 
       sources = generator.copied.map(&:first)
-      expect(sources).to match_array(%w[index.ts history.ts inbound.ts init_gate.ts media.ts metrics.ts send.ts sessions.ts package.json bun.lock])
+      expect(sources).to match_array(%w[index.ts history.ts inbound.ts init_gate.ts media.ts message_id.ts
+                                        metrics.ts send.ts sessions.ts package.json bun.lock])
       expect(sources.grep(/test|node_modules|\.wwebjs|\.puppeteer/)).to be_empty
       expect(generator.copied.map(&:last)).to all(start_with("whatsapp_service/"))
     end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: whatsapp_notifier
 version: !ruby/object:Gem::Version
-  version: 0.9.3
+  version: 0.9.4
 platform: ruby
 authors:
 - Kshitiz Sinha
@@ -91,6 +91,8 @@ files:
 - lib/whatsapp_notifier/services/web_automation/init_gate.ts
 - lib/whatsapp_notifier/services/web_automation/media.test.ts
 - lib/whatsapp_notifier/services/web_automation/media.ts
+- lib/whatsapp_notifier/services/web_automation/message_id.test.ts
+- lib/whatsapp_notifier/services/web_automation/message_id.ts
 - lib/whatsapp_notifier/services/web_automation/metrics.test.ts
 - lib/whatsapp_notifier/services/web_automation/metrics.ts
 - lib/whatsapp_notifier/services/web_automation/package.json