Page MenuHomePhabricator

[Tunnelbroker][lib] add `BadDeviceToken` message type
ClosedPublic

Authored by kamil on Jul 29 2024, 2:17 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Nov 9, 11:36 PM
Unknown Object (File)
Sat, Nov 9, 7:38 PM
Unknown Object (File)
Wed, Nov 6, 10:49 PM
Unknown Object (File)
Sat, Oct 19, 8:24 AM
Unknown Object (File)
Fri, Oct 18, 9:46 PM
Unknown Object (File)
Fri, Oct 18, 9:46 PM
Unknown Object (File)
Oct 11 2024, 10:34 PM
Unknown Object (File)
Oct 6 2024, 8:43 PM
Subscribers

Details

Summary

ENG-8498.

Similar to keyserver one but for Tunnelbroker.

Depends on D12909

Test Plan

Tested later in the stack.

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

kamil held this revision as a draft.
kamil published this revision for review.Jul 29 2024, 6:25 AM
kamil edited the summary of this revision. (Show Details)
kamil edited the test plan for this revision. (Show Details)
bartek added inline comments.
lib/types/tunnelbroker/peer-to-peer-message-types.js
115 ↗(On Diff #42862)

Just curious - why do we need the invalid token value?

This revision is now accepted and ready to land.Jul 29 2024, 8:15 AM
lib/types/tunnelbroker/peer-to-peer-message-types.js
115 ↗(On Diff #42862)

To handle some race conditions and messages delivered with delay:

  1. Tunnelbroker discovers token is invalid and queue message
  2. Device uploads a new device token (handlers trying to do it on each app load)
  3. BadDeviceToken is delivered.

In case 3 we just ignore the message because we're invalidating a different token (implemented in D12912).

lib/types/tunnelbroker/peer-to-peer-message-types.js
115 ↗(On Diff #42862)

Okay, this makes perfect sense to me, thanks for explaining