deps: move to bridge 0.19.0

README.md

@@ -243,6 +243,19 @@ A few behaviors that differ from upstream — almost always to your advantage:
   `connectTimeoutMs`, `qrTimeout`, `printQRInTerminal`, `ignoreOfflineMessages`,
   `downloadHistory`, `agent`, `fetchAgent`, `mobile`, `mediaCache`,
   `userDevicesCache`, `callOfferCache` and `placeholderResendCache`.
+- **A sender's resend reaches you once, not once per delivery.** When a
+  sender's network is bad, their client re-runs its own outbox and sends the
+  same message again — same `key.id`, re-encrypted. Upstream Baileys emits a
+  `messages.upsert` for each of those deliveries, so an auto-reply bot answers
+  the same message two or three times; the engine now recognises the repeat and
+  emits one. It is a short-lived, in-memory window (five minutes), so the one
+  case still open is a sender whose retry spans a restart of your process. If
+  your handler has side effects, keying them on the whole `key` — `remoteJid`,
+  `id`, `fromMe` and `participant` — remains the thing that makes it safe. Not
+  on `id` alone: the id is the sending client's to choose, so two participants
+  of one group can pick the same one, and a handler that keys on it would drop
+  the second person's message rather than a duplicate. That is why the engine's
+  own check carries the sender too.
 - **`Boom` ships in the box.** baileyrs exports its own
   `@hapi/boom`-compatible `Boom`, so the existing
   `(err as Boom).output.statusCode` pattern works unchanged. If your

package.json

@@ -82,7 +82,7 @@
   },
   "dependencies": {
     "@hapi/boom": "^9.1.4",
-    "@oxidezap/whatsapp-rust-bridge": "0.18.0",
+    "@oxidezap/whatsapp-rust-bridge": "0.19.0",
     "long": "^5.3.2",
     "pino": "^10.3.1",
     "protobufjs": "^7.6.5"