fix(engine): restore sending on Jul 2026 WhatsApp Web ($1 id rename) — temporary whatsapp-web.js fork pin

[dallascyclist]

What & why

WhatsApp Web's mid-July 2026 update renamed the message-id field id._serialized → id.$1. This breaks whatsapp-web.js 1.34.7 (the latest stable, Apr 2026):

• client.sendMessage() returns undefined
• presence / getChatById throw a minified r: r
• all outbound sending fails while receiving keeps working

Downstream, our adapter throws TypeError: Cannot read properties of undefined (reading 'id') on msg.id._serialized in sendTextMessage. On the prod translation bot this took the feature fully down (translations stopped posting) after a routine session reconnect on 2026-07-19.

Widely reported upstream: wwebjs/whatsapp-web.js#201836, #201838, #201849.

⚠️ This is a TEMPORARY fix — read before relying on it

The dependency is pinned to a community fork commit, not an official release:

• whatsapp-web.js → https://codeload.github.com/lindionez/whatsapp-web.js/tar.gz/f4ea1e3cf4076e44e36dfe5f81ea57048d2f7761
• Source: lindionez/whatsapp-web.js @ f4ea1e3, the head of PR fix(client): add fallback for WhatsApp id._serialized renamed to id.$1 wwebjs/whatsapp-web.js#201832 (feat/fix-_serialized-id-fallback), which adds a $1 → _serialized shim (Base._normalizeId() + fallbacks across Structures / Util.js / Client.js).
• Pinned to an exact commit + integrity hash in the lockfile — no floating ref.
• There is no patched official release yet (npm 2.0.0-alpha.0 is a dead 2023 tag; 1.34.7 is the newest stable).

Trade-offs to be aware of:

• It's a third party's fork. Vetted only insofar as the diff is a targeted ID-normalization shim and it's the fix referenced by multiple affected users in #201832.
• Known residual (wwebjs#201849): group sends may show "Waiting for this message" on the bot's own linked phone, but are readable by other group members — acceptable for a translation bot.

🔁 Revert plan (do this once upstream ships a real fix)

1. Watch wwebjs/whatsapp-web.js releases / npm for a version carrying the $1 fix.
2. Set "whatsapp-web.js": "^1.34.x" (or the fixed version) in package.json.
3. npm install to regenerate the lock → rebuild → redeploy → re-run the self-send check.
4. Keep the error.stack logging change below — it's unrelated to this incident.

Also included (keepers, independent of the fork)

• Surface error.stack in the plugin logger (plugin-loader.service.ts). It was collapsing thrown errors to .message, which is exactly why the real error only ever showed as the opaque "r". This is what made the root cause visible.
• Add chatId / author / errorType to the translation hook's error log for attribution.

Verification

Built and deployed to prod. Post-patch self-send:

POST …/messages/send-text  → HTTP 201  {"messageId":"true_…_out", …}
DB record:                  status: sent | waMessageId: true_…_out   (was: failed / null)
adapter/plugin errors:      none

Not in this PR (deployment-side)

The deployment also gained a plugin-init compose sidecar that re-enables the translation extension plugin on docker compose up (extension plugins register disabled and don't persist enabled-state). It lives in the gitignored, deployment-local docker-compose.override.yml, so it's intentionally excluded here.

https://claude.ai/code/session_01HeKGtw8knz2S8vumAT7BhT