Something mentioned in this comment.
Authoritative keyserver owner shouldn't call this RPC. Otherwise, the primary-device-issued device list will be a singleton that doesn't contain the keyserver.
Details
Details
Mocked my user ID to be authoritative keyserver owner. Confirmed that the RPC fails.
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
Comment Actions
What RPC should the authoritative keyserver owner's primary device call instead? I suppose we should be calling a "v1" RPC instead of a v2 one, and the fact that the wrong one was called is a client issue?
Comment Actions
It's 3. from this Linear comment. For authoritative keyserver owner, v1 fallback should be triggered.
- Ashoat tries restore flow. Backup exists, so it doesn't fall back to v1. RestoreUser RPC is called, which likely fails with use_v1_flow due to unsigned device list. The "Unknown error" is displayed.
- Thankfully it failed, otherwise primary-device-issued device list update would be a singleton without authoritative keyserver device present. I'm going to handle this case separately to prevent it from happening.