> ## Documentation Index
> Fetch the complete documentation index at: https://whatsapp-rust.jlucaso.com/llms.txt
> Use this file to discover all available pages before exploring further.

# June 9, 2026 — Retry: device-list resync on unknown-device retry

> Fixed an infinite retry loop where a newly-linked device absent from the local registry would retry group messages forever because it was never included in subsequent sends. Retries from unknown devices now trigger a device-list resync, learning the device for the next send.

## Fixes

**Device-list resync triggered on retry from unknown device ([#802](https://github.com/oxidezap/whatsapp-rust/pull/802))**

**The problem.** When a contact links a new device after your last device-list sync, your local registry does not know about it. The device receives your group `skmsg` from the server but never got a sender key, so it can only fail to decrypt and send a retry receipt. The previous fix ([#795](https://github.com/oxidezap/whatsapp-rust/pull/795)) recovered retries that carry a `<keys>` bundle by building a fresh Signal session from the bundle and resending. But a retry that arrives *without* a bundle was simply dropped — and nothing scheduled a resync. The reconciliation that fires when a prekey fetch returns 406 during a send never triggered for this device either, because the device was not in the set being sent to. The result: the device was never learned, retries continued indefinitely, and the user's new device never received messages.

**The fix.** A retry from an unknown device is now treated as a staleness signal regardless of whether it carries a bundle. `handle_retry_receipt` calls `schedule_unknown_device_sync` for any requester that is missing from the local device registry, *before* consulting `should_drop_unknown_device_retry`. The method deduplicates per user via `PendingDeviceSync` so a retry storm from one unknown device cannot fan out into a usync storm. Once the resync completes, the device appears in the registry, the next send includes it in the sender-key distribution, and the retries stop. This mirrors WA Web's `syncDeviceListJob` trigger on the retry path.

The drop predicate (`!keys_present && !device_known`) is unchanged — a retry without a bundle is still not recovered for the *current* message. The resync ensures it is recovered on the *next* send.

**Impact.** If a contact linked a new device after your last usync, messages you sent to that contact's group would be missing that device indefinitely. The device now self-heals on the next send after the resync completes. No API changes. No breaking changes.