Page MenuHomePhabricator

[services] Tunnelbroker - Update handling of the `newNotifyToken` in `Get` stream request
ClosedPublic

Authored by max on Sep 21 2022, 3:37 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, May 2, 3:34 PM
Unknown Object (File)
Thu, May 2, 3:34 PM
Unknown Object (File)
Thu, May 2, 3:33 PM
Unknown Object (File)
Thu, May 2, 3:13 PM
Unknown Object (File)
Tue, Apr 30, 5:31 PM
Unknown Object (File)
Tue, Apr 30, 5:31 PM
Unknown Object (File)
Tue, Apr 30, 5:31 PM
Unknown Object (File)
Tue, Apr 30, 5:31 PM

Details

Summary

This diff introduces handling of the newNotifyToken in Get stream request.
When the device has an invalid or expired notification token we are requesting a new token from the client (ref to D5207).
The client gets back with the new token in Get stream request when starts listening for new messages (getting messages) from the Tunnelbroker.

This is a part of the stack.
This approach was used keeping in mind the transition to the bidirectional stream soon.

Related Linear task: ENG-1782 and ENG-1816

Test Plan

Successfully built the service and passed unit and integration tests.

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

max held this revision as a draft.
max edited the test plan for this revision. (Show Details)
max added a reviewer: tomek.

LGTM, as long as https://phab.comm.dev/D5207 lands at the same time.

For dealing with more cases in the future, I think we should eventually do something like:

if (request->has_newnotifytoken()) {
  handle_new_notify_token(request);
} (request->has_ping()) {
  handle_ping(request);
}

Where we deconstruct some of the information, and able to write functions which deal with more specific scenarios. May also allow for some unittests, if it's just "data in, data out".

services/tunnelbroker/src/Service/TunnelbrokerServiceImpl.cpp
185–192 ↗(On Diff #16968)

concerned about this being partial (only handles , but looks like https://phab.comm.dev/D5207 handles the new token logic, not sure if in the future, we should just combine these types of diffs. Although your summary mentions D5207, I would expect for a commit to handle more of the vertical slice.

Maybe it's just me, but I'm not a big fan of "intermediate diffs".

Not sure how @ashoat feels.

services/tunnelbroker/src/Service/TunnelbrokerServiceImpl.cpp
185–192 ↗(On Diff #16968)

I agree, this would be easier to review as one diff imo

services/tunnelbroker/src/Service/TunnelbrokerServiceImpl.cpp
185–192 ↗(On Diff #16968)

Meant to say "only handles the database write failure"

This revision is now accepted and ready to land.Sep 23 2022, 5:02 AM
max added inline comments.
services/tunnelbroker/src/Service/TunnelbrokerServiceImpl.cpp
185–192 ↗(On Diff #16968)

concerned about this being partial (only handles , but looks like https://phab.comm.dev/D5207 handles the new token logic, not sure if in the future, we should just combine these types of diffs. Although your summary mentions D5207, I would expect for a commit to handle more of the vertical slice.

It's split by the functionality actions: we are updating, we are requesting. This follows the phabricator convention to make smaller diffs but each diff should not break the building of the app.

Maybe it's just me, but I'm not a big fan of "intermediate diffs".

Sometimes it's necessary. I think the main decision when splitting into smaller chunks/diffs is to think as a reviewer and how would be better to review it. Maybe sometimes is too much splitting. Thanks for your thoughts @jon !

185–192 ↗(On Diff #16968)

I agree, this would be easier to review as one diff imo

Ok, I'll take it into account!

185–192 ↗(On Diff #16968)

Meant to say "only handles the database write failure"

We are updating the new token in the database here and handling the possible error on this operation.