Fixes
Device-list resync triggered on retry from unknown device (#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 groupskmsg 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) 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.