this update reflects the changes to InboundKeysForUserResponse made in D10560.
the codegen had a hard time with the oneOf's, so had to make some manual changes to the .flow file
Differential D10587
[web] update grpc-web codegen varun on Jan 9 2024, 11:20 PM. Authored by Tags None Referenced Files
Subscribers
Details
this update reflects the changes to InboundKeysForUserResponse made in D10560. the codegen had a hard time with the oneOf's, so had to make some manual changes to the .flow file called getInboundKeysForUser on my local identity service from root.js and got back a response containing a wallet address and social proof.
Diff Detail
Event Timeline
Comment Actions I'm a bit worried that the custom changes here will break the codegen verification script @bartek is working on in ENG-6383. Setting him as blocking to make sure there aren't any conflicts. If the oneof approach we're taking here results in too much codegen weirdness, we could consider option 1 of ENG-6372 (Sidenote – I really think the codegen updates should be included in the diff that updates the proto going forward. In this case, the codegen gave us some surprises that might force us to go rethink the approach in the proto file. ENG-6383 should help with this.)
Comment Actions As long as we don't modify .cjs files manually (non-flow), this doesn't conflict with ENG-6383.
|
This logic is a bit confusing.
I guess the reason we decided to store a separate deviceToken per keyserver is because we want to know if we've shared our deviceToken to that keyserver yet, not because we expect to have a different deviceToken per keyserver.
It would probably make more sense if we have a deviceTokenHasBeenUploaded: boolean in KeyserverInfo, and a deviceToken field at the top level of Redux. But we'll likely end up removing deviceTokens from keyservers soon anyways...