Page MenuHomePhabricator

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

Authored by angelika on Fri, Oct 25, 2:09 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Nov 18, 4:00 PM
Unknown Object (File)
Sun, Nov 17, 4:38 PM
Unknown Object (File)
Fri, Nov 15, 7:19 PM
Unknown Object (File)
Sun, Nov 10, 1:29 PM
Unknown Object (File)
Sun, Nov 10, 6:26 AM
Unknown Object (File)
Fri, Nov 8, 11:06 PM
Unknown Object (File)
Fri, Nov 8, 6:47 PM
Unknown Object (File)
Wed, Nov 6, 2:56 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
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

kamil requested changes to this revision.Tue, Oct 29, 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.Tue, Oct 29, 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.Wed, Oct 30, 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