Page MenuHomePhabricator

[lib] Wait with processing inbound messages for Tunnelbroker connection
ClosedPublic

Authored by angelika on Oct 25 2024, 2:09 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Dec 19, 1:49 AM
Unknown Object (File)
Sun, Dec 15, 7:56 PM
Unknown Object (File)
Sun, Dec 15, 7:56 PM
Unknown Object (File)
Sun, Dec 15, 7:56 PM
Unknown Object (File)
Sun, Dec 15, 7:56 PM
Unknown Object (File)
Sun, Dec 15, 7:54 PM
Unknown Object (File)
Sun, Dec 15, 7:50 PM
Unknown Object (File)
Thu, Nov 28, 6:06 AM
Subscribers

Details

Summary
Test Plan
  1. Comment out code in removeInboundP2PMessages() function
  2. Send some messages
  3. Now getAllInboundP2PMessages() should always return something
  4. Restart the app
  5. Verify that:
  6. before the patch in the logs there are errors like "Error while sending confirmation: Tunnelbroker not connected [Error: Tunnelbroker not connected]"
  7. after the patch the errors should disappear

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

kamil requested changes to this revision.Oct 29 2024, 6:12 AM

I would prefer a slightly different approach, where we could read Inbound messages and add them to the queue, there is no point in deffering this - but instead wait with actual processing, to achieve that we might need to modify useActionsQueue to be able to conditionally start processing, what do you think?

Additionally, this could mitigate ENG-9713 - when there is no TB connection, we won't decrypt message which could not be confirmed to Tunnelbroker.

Requesting to discuss this - but I am open to accepting this too if you think what I suggested has some drawbacks.

This revision now requires changes to proceed.Oct 29 2024, 6:12 AM
kamil added inline comments.
lib/tunnelbroker/peer-to-peer-message-handler.js
109 ↗(On Diff #45449)

shouldn't we memoize it?

This revision is now accepted and ready to land.Oct 30 2024, 3:08 AM
lib/tunnelbroker/peer-to-peer-message-handler.js
109 ↗(On Diff #45449)

I don't think there's any point to memoizing this.

There are two reasons for memoizing something in React using useMemo:

  1. (More important reason) to avoid regenerating non-primitives. React does a lot of comparisons to determine if things change, so if you're generating a new object, array, etc. each time, you'll force React to re-render a bunch of things
  2. If you have an expensive calculation, memoization can let you avoid doing it multiple times unnecessarily.
lib/tunnelbroker/peer-to-peer-message-handler.js
109 ↗(On Diff #45449)

Ahh right, sorry for confusing