diff --git a/crates/matrix-sdk-crypto/src/identities/manager.rs b/crates/matrix-sdk-crypto/src/identities/manager.rs
index e66ad893970..28ab62eba87 100644
--- a/crates/matrix-sdk-crypto/src/identities/manager.rs
+++ b/crates/matrix-sdk-crypto/src/identities/manager.rs
@@ -169,13 +169,15 @@ impl IdentityManager {
         // user identities from the store, so this has to happen *after* the
         // changes from `handle_cross_signing_keys` are saved.
         //
-        // FIXME: This thing is racy. If a session is created at the same time as a
-        //   `/keys/query` response is being processed, it could be saved
-        //   without up-to-date sender data, but it might be saved too late for
-        //   it to be picked up by `update_sender_data_from_device_changes`.
-        //
-        // FIXME: Come to that, what if this races against some other operation on the
-        //   session, such as marking it as needing backup? It's all a bit terrifying.
+        // Note: it might be possible for this to race against session creation. If a
+        // new session is received at the same time as a `/keys/query` response is being
+        // processed, it could be saved without up-to-date sender data, but it might be
+        // saved too late for it to be picked up by
+        // `update_sender_data_from_device_changes`. However, this should be rare,
+        // since, in general, /sync responses which might create a new session
+        // are not processed at the same time as /keys/query responses (assuming
+        // that the application does not call `OlmMachine::receive_sync_changes`
+        // at the same time as `OlmMachine::mark_request_as_sent`).
         self.update_sender_data_from_device_changes(&devices).await?;
 
         // if this request is one of those we expected to be in flight, pass the