HomePhabricator
Diffusion Comm 84a3b0a52f69

[lib] refactor sequential handling of Tunnelbroker messages

Description

[lib] refactor sequential handling of Tunnelbroker messages

Summary:
This is a fix for ENG-8968.

In the previous implementation, peerToPeerMessageHandler was not always reactive to state changes, this scenario was possible:

  1. peerToPeerMessageHandler is a callback and memoized based on current dependencies.
  2. tunnelbrokerMessageListener is invoked two times in a row with create_thread, and send_text_message. There is a promise created for create_thread and immediately there is a second one spawned for send_text_message (with the memoized value of peerToPeerMessageHandler).
  3. Promise for create_thread is resolved, it causes some changes in the thread store.
  4. Promise for send_text_message is starting, but it is using the memoized value of peerToPeerMessageHandler (from point 1), at that time, the DM thread is not yet in the store, so this fails because there is no thread associated with the text message.

This fix makes sure, that we always use an updated version of peerToPeerMessageHandler. Instead of changing promises, use messages queue, peerToPeerMessageHandler is called right before execution, not ahead of time.

Test Plan:

  1. Open two clients, A and B.
  2. Makes B goes offline.
  3. On A, send thread creation and a couple of text messages.
  4. Open Client B.
  5. Thread and all DM messages are visible.

Additionally, testing this effect does not do any unnecessary computations.

Reviewers: tomek, inka

Reviewed By: tomek

Subscribers: ashoat

Differential Revision: https://phab.comm.dev/D13078

Details

Provenance
kamilAuthored on Aug 14 2024, 8:02 AM
Reviewer
tomek
Differential Revision
D13078: [lib] refactor sequential handling of Tunnelbroker messages
Parents
rCOMM345064750f40: [lib] resend messages after race condition
Branches
Unknown
Tags
Unknown