> ## 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 — Device list: primary device preserved on identity rotation

> Fixed a bug where a companion relink or identity rotation could silently drop device 0 from the stored device list, preventing encrypted messages from reaching the primary phone.

## Fixes

**Device list always retains primary after identity rotation ([#797](https://github.com/oxidezap/whatsapp-rust/pull/797))**

**The problem.** When a device-add notification arrives with a `raw_id` that differs from your stored value, `patch_device_add` clears the device list and rebuilds it from the notification. `filter_devices_by_key_index` only keeps device 0 if it is already present in the input. After the clear, device 0 is gone. The rebuilt list ends up as something like `[{device_id: 19}]`, or empty if the notified device's key index is rejected.

`get_user_devices` treats any existing record as authoritative. It only goes to the network when there is no record at all. So the broken list sticks. The self-healing usync re-fetch never fires. Every subsequent encrypted send to that contact skips their primary phone.

**The fix.** `patch_device_add` now unconditionally re-adds device 0 after every rebuild. This mirrors `WAWebHandleAdvDeviceNotificationApi.handleDeviceAddNotification`, which always pushes `{ id: DEFAULT_DEVICE_ID, keyIndex: 0 }` back onto the list. whatsmeow enforces the same invariant.

**Impact.** If a contact performed a companion relink or identity rotation during your session, messages you sent afterward could silently miss their primary phone until the next full usync ran. No API changes. No breaking changes.