Toast "key storage out of sync" visible even though things seem fine.

[andybalaam]

Steps to reproduce

1. Log in
2. Successfully verify using another device

This was on a dev instance, so I uploaded the logs manually here:

console-export-2026-1-29_13-31-31.log.gz

Outcome

What did you expect?

To be properly verified, and to see no warning about it.

What happened instead?

I saw a "Your key storage is out of sync" toast.

But my crypto setup seems fine.

When I refresh, the toast does not reappear, which makes me confident that there is nothing actually wrong with my crypto setup.

Operating system

Debian 12

Browser information

Firefox 147.0.1

URL for webapp

Commit ID: 5e21c8d

Application version

Element version: 1.12.8-dev Crypto version: Rust SDK 0.16.0 (3e8e0fb), Vodozemac 0.9.0

Homeserver

local Synapse, fairly out of date

Will you send logs?

Yes

[BillCarsonFr]

I can reproduce on a local setup too

1. Create a new account on EW for new_guy
2. Start a direct chat with alice
3. There is a popup asking to setup recovery, just do it (follow the step, copy paste recovery)

From another context in a new tab:

1. Log in this new account
2. Verify with another device -> follow the step and verify succesfully.

Then you have this unexecpected Popup

I can see from the logs that all the secrets are received.

The failing check seems to be

[richvdh]

This was on a dev instance, so I uploaded the logs manually here:

Aside: setting up a dev instance to report to the rageshake server is pretty easy: just stick "bug_report_endpoint_url": "https://element.io/bugreports/submit" in config.json

[richvdh]

(which would be good, because saving from the console isn't quite as verbose as what gets sent to the rageshake server).

Still, andy's logs say:

13:22:47.379 DeviceListener: check_dU3p: 4S is missing secrets or backup key not cached
Object { crossSigningReady: true, secretStorageStatus: {…}, allCrossSigningSecretsCached: true, isCurrentDeviceTrusted: true, keyBackupDownloadIsOk: false }

This looks like a race against receiving the key from the other device, because shortly before, we have:

13:22:47.353 INFO matrix_sdk_crypto::gossiping::machine: Received a backup decryption key, storing it into the secret inbox.

and afterwards:

13:22:47.412 handleBackupSecretReceived: A valid backup decryption key has been received and stored in cache. init.js:76300:19

So, basically, the DeviceListener needs to add CryptoEvent.KeyBackupDecryptionKeyCached to the list of events it listens for.

[richvdh]

So, basically, the DeviceListener needs to add CryptoEvent.KeyBackupDecryptionKeyCached to the list of events it listens for.

Taking this off the maintainer queue for the fix above to happen