@oxidezap/whatsapp-rust-bridge 0.7.0 → 0.7.2

package/dist/whatsapp_rust_bridge.d.ts

@@ -577,6 +577,21 @@ export type EditAttribute = "" | "1" | "2" | "3" | "7" | "8" | string;
 /** Which terminal outcome another of our devices reached for a call we were ringing for. */
 export type ElsewhereOutcome = "accepted" | "rejected";
 
+/** Payload of [`Event::EncDecryptFailed`]: one `<enc>` of a stanza that produced no plaintext, and why.  The failing half of what [`DecryptedPayload`] reports for the succeeding half, at the same granularity and under the same numbering. A stanza can carry one `<enc>` per device; without a per-node signal a consumer watching decryption can say *this `<enc>` produced these bytes* but not *this `<enc>` failed for this reason*, and on a fan-out not even which one failed.  Reasons to want it: attributing a failure inside a fan-out, driving a retry or resync policy off the reason, and measuring session health per peer rather than per message.  # What it does not say  - **It is not a display signal.** Whether to show the user a placeholder is [`Event::UndecryptableMessage`], which is per *message*, deduplicated by `(chat, id)`, and carries the server's `decrypt-fail` hint. This event is per `<enc>`, is not deduplicated, and answers a different question. - **It is not a loss report.** Most reasons are recoverable — the client may already have asked the sender to resend — and this event says nothing about whether a retry went out or whether one succeeded later. - **It repeats.** A redelivered stanza that fails again emits it again, once per `<enc>` per delivery. Correlate on `info.id` if you want at-most-once. - **A duplicate is not a failure.** An `<enc>` the server redelivered that this device already processed emits neither this nor [`DecryptedPayload`]: its plaintext was reported the first time round, and calling that a failure would put two meanings in one event. The silence covers the duplicate `<enc>` itself and nothing more: a stanza whose session `<enc>` were duplicates and nothing else has its `skmsg` decrypted normally, and one where a duplicate arrives beside an `<enc>` that genuinely failed skips that `skmsg` on every delivery — so the skip is reported as [`NotAttempted`](EncDecryptFailureReason::NotAttempted), because no delivery ever produced its plaintext. - **Order is `enc_index`, not arrival.** The client decrypts a stanza's `<enc>` nodes in per-kind passes (session, then group, then bot), so neither these events nor [`DecryptedPayload`]s arrive in stanza order, and a failure for a later `<enc>` can precede a success for an earlier one. Within one stanza both kinds come from the same receive task, so they are totally ordered relative to each other — just not by position.  Gated by `Client::acquire_enc_decrypt_failed_forwarding()`: nothing is emitted, and nothing is built, while no consumer holds a lease. */
+export interface EncDecryptFailed {
+    /** Which message this `<enc>` belongs to. */
+    info: MessageInfo;
+    /** Which `<enc>` of the stanza this was, counting from zero in the order the client enumerates them — the same numbering as [`DecryptedPayload::enc_index`], produced by the same enumeration, so the two events index one stanza and not two.  That order is the stanza's direct `<enc>` children first, then the ones under `<participants><to>` addressed to this device. It is *not* a child index. */
+    enc_index: number;
+    /** The `type` attribute the `<enc>` carried: `msg`, `pkmsg`, `skmsg`, …  `None` only when the node carried no `type` at all, which is also the one thing [`MalformedNode`](EncDecryptFailureReason::MalformedNode) can mean here that a present type does not. Borrowed for the types this build knows, owned for a `type` it does not. */
+    enc_type?: string | null;
+    /** Where the client stopped. */
+    reason: EncDecryptFailureReason;
+}
+
+/** Why one `<enc>` produced no plaintext.  Every variant names a branch the receive path actually takes; there is no catch-all "other" standing in for code nobody wrote. New branches append new variants, so this is `#[non_exhaustive]` and a match on it needs a `_` arm.  This is the client's own classification of where *it* stopped, not something the server sends and not a statement about the sender's copy. Two builds can classify the same ciphertext differently as branches are refined; the pairing of a reason with a specific `<enc>` is the stable part, the exact variant is not. */
+export type EncDecryptFailureReason = "MalformedNode" | "UnsupportedEncType" | "MalformedCiphertext" | "NoSession" | "NoSenderKey" | "UnknownPreKey" | "UntrustedIdentity" | "BadMac" | "InvalidMessage" | "NoMessageSecret" | "LocalCryptoFailure" | "SignalError" | "StorageFailure" | "PlaintextUnusable" | "NotAttempted";
+
 /** Review state for an appeal on a suspended group. */
 export type GroupAppealStatus = "approved" | "in_review" | "none" | "rejected";
 
@@ -4580,12 +4595,12 @@ export interface InitOutput {
     readonly intounderlyingsink_write: (a: number, b: number) => number;
     readonly intounderlyingsource_cancel: (a: number) => void;
     readonly intounderlyingsource_pull: (a: number, b: number) => number;
-    readonly __wasm_bindgen_func_elem_4243: (a: number, b: number, c: number) => void;
-    readonly __wasm_bindgen_func_elem_25775: (a: number, b: number, c: number, d: number) => void;
-    readonly __wasm_bindgen_func_elem_25777: (a: number, b: number, c: number, d: number) => void;
-    readonly __wasm_bindgen_func_elem_9064: (a: number, b: number, c: number) => void;
-    readonly __wasm_bindgen_func_elem_4242: (a: number, b: number, c: number) => void;
-    readonly __wasm_bindgen_func_elem_4241: (a: number, b: number) => void;
+    readonly __wasm_bindgen_func_elem_4245: (a: number, b: number, c: number) => void;
+    readonly __wasm_bindgen_func_elem_25789: (a: number, b: number, c: number, d: number) => void;
+    readonly __wasm_bindgen_func_elem_25791: (a: number, b: number, c: number, d: number) => void;
+    readonly __wasm_bindgen_func_elem_9069: (a: number, b: number, c: number) => void;
+    readonly __wasm_bindgen_func_elem_4244: (a: number, b: number, c: number) => void;
+    readonly __wasm_bindgen_func_elem_4243: (a: number, b: number) => void;
     readonly __wbindgen_export: (a: number, b: number) => number;
     readonly __wbindgen_export2: (a: number, b: number, c: number, d: number) => number;
     readonly __wbindgen_export3: (a: number) => void;

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@oxidezap/whatsapp-rust-bridge",
-    "version": "0.7.0",
+    "version": "0.7.2",
     "description": "A high-performance utilities for WhatsApp, powered by Rust and WebAssembly.",
     "author": "João Lucas <jlucaso@hotmail.com>",
     "license": "MIT",