Page MenuHomePhabricator

[lib] handle race condition when creating `olm` session
ClosedPublic

Authored by kamil on Apr 9 2024, 4:45 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Nov 3, 8:47 AM
Unknown Object (File)
Oct 12 2024, 10:58 PM
Unknown Object (File)
Oct 12 2024, 10:58 PM
Unknown Object (File)
Oct 12 2024, 10:58 PM
Unknown Object (File)
Oct 12 2024, 10:58 PM
Unknown Object (File)
Oct 12 2024, 10:58 PM
Unknown Object (File)
Oct 12 2024, 10:58 PM
Unknown Object (File)
Oct 12 2024, 7:18 AM
Subscribers

Details

Summary

This is the code that chooses which session to keep and which to reset.

When there is a race condition and the device has a higher deviceID - ignore the request (the other device will get our session request and then decide to accept the session as it has a lower deviceID). Already queued messages can be ignored, while decrypting we will get OLM_SENDER_CHAIN_NOT_ACKNOWLEDGED which is different than BAD_MESSAGE_MAC so those messages will not cause a resetting session again.

When there is a race condition and the device has a lower deviceID - overwrite session and resend all messages, there is a separate task to work on this (see comment).

Depends on D11595

Test Plan
  1. Create two new devices.
  2. Hardcode session versions (high value).
  3. Send session request - should be created.
  4. Send session request again - this simulates race condition (one device already have session with ID and receives request with the same ID).
  5. Device should ignore it to accept depending on deviceID - tested both cases.

Diff Detail

Repository
rCOMM Comm
Branch
land-session-work
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

kamil held this revision as a draft.
This revision is now accepted and ready to land.Apr 11 2024, 1:00 AM