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)
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)
Fri, Oct 11, 10:34 PM
Unknown Object (File)
Oct 6 2024, 8:43 PM
Unknown Object (File)
Sep 23 2024, 9:59 AM
Unknown Object (File)
Sep 19 2024, 4:50 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
Branch
publish-device-token
Lint
No Lint Coverage
Unit
No Test Coverage

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

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

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

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