Page MenuHomePhabricator

[Identity] Issue refresh_key_request to tunnelbroker
ClosedPublic

Authored by jon on Aug 7 2023, 7:51 AM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Apr 16, 10:41 PM
Unknown Object (File)
Tue, Apr 16, 7:39 AM
Unknown Object (File)
Tue, Apr 16, 2:05 AM
Unknown Object (File)
Mon, Apr 15, 6:22 AM
Unknown Object (File)
Mon, Apr 15, 3:17 AM
Unknown Object (File)
Mon, Apr 15, 12:26 AM
Unknown Object (File)
Sun, Apr 14, 11:44 PM
Unknown Object (File)
Sun, Apr 14, 7:58 AM
Subscribers

Details

Summary

Have identity service issue a request to users when refresh keys
when the key count goes below the threshold.

https://linear.app/comm/issue/ENG-4446

Depends on D8723

Test Plan

Integration tests are in next diff

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

services/identity/src/database.rs
388–389 ↗(On Diff #29584)

Do we have to wait for these? Can it be done concurrently, without blocking the single onetime key acquisition?

services/identity/src/database.rs
388–389 ↗(On Diff #29584)

It needs to be awaited (futures that aren't awaited never get executed). But could probably do something like tokio::spawn to move it to a different thread. It my plan originally, but I just wanted something easier to reason about while implementing this.

The other item I thought of, and is probably a better solution, would be to introduce a mpsc channel to a dedicated tunnelbroker channel. It would also avoid the overhead of a connection for every request.

390 ↗(On Diff #29584)

This is just to avoid the "Result not inspected" warning. It will emit the error in logs.

services/identity/src/database.rs
387–390 ↗(On Diff #29584)

Yep, let's try tokio::spawn and see if it works

The other item I thought of, and is probably a better solution, would be to introduce a mpsc channel to a dedicated tunnelbroker channel. It would also avoid the overhead of a connection for every request.

Good idea. This can be done as a follow-up I think.

varun added 1 blocking reviewer(s): bartek.

some nits/comments inline. adding @bartek as blocking so the tokio::spawn change gets added

services/identity/src/constants.rs
131–133 ↗(On Diff #29584)

how did we decide on these values?

131–133 ↗(On Diff #29584)

ONE_TIME_KEY_...

services/identity/src/database.rs
379–385 ↗(On Diff #29584)
jon marked 5 inline comments as done.

Apply suggestions

services/identity/src/constants.rs
131–133 ↗(On Diff #29584)

how did we decide on these values?

It was pretty informal, I think a one-on-one or some crypto sync. Don't think it was ever documented.

I just need something though to start with. We can discuss this as part of a crypto sync if you do have concerns. I don't think I'm informed enough to know what the correct numbers would be.

ONE_TIME_KEY_...

This is address treewide in D8817

services/identity/src/database.rs
379–385 ↗(On Diff #29584)

After realizing that my let-else issues were related to not running rustup update since February, I decided to use @bartek suggestion.

This revision is now accepted and ready to land.Aug 17 2023, 10:12 AM