Race on account creation causing upload of 100 OTKs instead of 50

[BillCarsonFr]

Can be reproduced on EX.

After login, the sdk will schedule:

• The upload the current device keys
• The first encryption sync

We can see from the logs that the initial key/upload is handled first. This initial upload also contained 50 otks, so the one time key count is updated

matrix-rust-sdk/crates/matrix-sdk-crypto/src/olm/account.rs

Lines 1222 to 1226 in fbc914f

	debug!("Marking one-time keys as published");
	// First mark the current keys as published, as updating the key counts might
	// generate some new keys if we're still below the limit.
	self.mark_keys_as_published();
	self.update_key_counts(&response.one_time_key_counts, None);

11-06 11:38:16.085 Updated uploaded one-time key count 0 -> 50. | crates/matrix-sdk-crypto/src/olm/account.rs:535 | spans: keys_upload{request_id="353c874435e841c294845723da7d190a"}

Then in a quick race the first sync response is handled, the sync response says:

"device_one_time_keys_count": { "signed_curve25519": 0 },

So the one time key count is updated again to 0 this time.

matrix-rust-sdk/crates/matrix-sdk-crypto/src/machine/mod.rs

Lines 1390 to 1393 in fbc914f

	account.update_key_counts(
	sync_changes.one_time_keys_counts,
	sync_changes.unused_fallback_keys,
	)

11-06 11:38:16.091  Updated uploaded one-time key count 50 -> 0. | crates/matrix-sdk-crypto/src/olm/account.rs:535 | spans: next_sync_with_lock > sync_once > handle_response > preprocess_to_device_events > receive_sync_changes

As a consequence the sdk considers that the intial 50 keys have been used, so it will generate new ones.

Not sure if this behavior could cause problems.

If I remind correctly on legacy sdk we never considered the response of key/upload to update the published count of one time key.
Instead we only track the count that we got from the sync.
That means that after the fisrt sync the current count was considered unknown, thus an empty key/upload call was made to have the current count.

Maybe could avoid this scenario?, but we expect the sync response to be valid (see element-hq/synapse#17491)

[BillCarsonFr]

Another strange thing is that the initial key upload is uploading 50 OTKS but no fallback key.

Maybe we want the initial device key upload to only upload the device keys and no otk?

[andybalaam]

We think this is minor because it doesn't break anything.