RPC Timeout when sharing vaults with another user #166
Assignees
Labels
bug
Something isn't working
r&d:polykey:core activity 1
Secret Vault Sharing and Secret History Management
Comments
|
When a vault is shared it does two things.
The first step is blocking but quick, it shouldn't be causing this issue. But the 2nd step where we send a notification requires establishing a connection to the target. If we fail to do that and wait for the connection to time out then it's very likely the RPC will timeout first, thus causing this issue. To fix this, the notification step needs to be non-blocking. To this end we need to make the following changes.
|
|
While discussing this, there is also a feedback problem. All we're getting is the RPC timeout error. If it was a client side error then there is no context we can gleam from it. From the client's perspective the RPC just stopped responding. From the server's perspective, timeout is a timeout, we'd have to manually include the context of what it was trying to do. A really basic way to address this is to expand the error with some context or include some metadata we can add context during each step of the handler. This metadata object can be included with the RPC error message. If we want some real-time feedback then we'd need to update the RPC system with out-of-band messaging which is something we've tried to avoid so far. |
|
So when we did this demo, I had 2 Cryptolinks with Polykey. We know that the system doesn't know how to handle multiple Cryptolinks (GH gists with Polykey). Sometimes the My hunch is that now that i have deleted my cryptolinks and started a fresh PK node, if @asuarezop and myself were to go through the discovery, trust, and share vault process again, we should not run into anymore errors. |
|
@tegefaulkes Got the same RPC Error Issues with Nguyen which I got with @asuarezop but both users only had deleted all gestalts and had both created a fresh node and started the Polykey demo from scratch. Steps to recreate Bugyou can view this demo recording here Providing Terminal History from Wen HereTerminal 1Opened up 2nd terminal (below) while Polykey was running on the 1st terminal (above).Opened up 3rd terminal to continue gathering more data. Notice that we ran Polykey agent stop in the wrong terminal because technically its still running in the first terminal but was never properly shut down.Providing Terminal history from Pablo HereThis was the terminal history from when i created the fresh PK node from scratch with BrianTerminal 1 windowTerminal 2 Where Brian and I created a success case (benchmark)Terminal 3 The Demo with Wen |
|
In both cases here it seems you're failing to connect to each other. Can you give me more details about the network each person is on? If you could provide details about the following for each person.
AS for more detail to why this is happening. If you can't connect to each other you can't really interact with each other. That means you can't clone vaults, send notification and by extension share a vault. We've done a lot of work to streamline making connections to each other without user input. But there are two main cases that we can't fully solve just by the nature of how networks work.
So unless we can rule out these two cases, I can't confidently claim that this is a bug except for the previously discussed poor feedback with the |
|
Oh and don't use |
Pablo's Environment
Wen's Environment @duynguyen1105
|
|
After today's meeting we pretty much confirmed that the problem was that @duynguyen1105 has a symmetric NAT. We currently have no way to automate a connection through one of these NATs so the problem is explicitly NOT a bug. We just don't support that kind of CAT. In the future we'll add more features to work around these kinds of NATs such as automated port forwarding protocols such as uPNP, or relaying. |
|
Going to Demo again with @asuarezop sometime on Wednesday:
|
|
If you want to do everything from scratch then yeah, start the node fresh and delete the old cryptolinks gists. For the most part you want to retread the steps we took to determine if connections can be made between each other and if not, why not. |
|
@tegefaulkes If user A using 1 node has already discovered user B via their github gestalt, but then user B creates a fresh node and a new cryptolink, I believe user A would still be viewing (In identities list) the old cryptolink (even if destroyed) along with the old node (even if abandoned). Is there a way that user A can delete a discovered identity in their identities list so that discovery can be re-run to show the new information associated with user B? |
|
Right now we don't have the ability to do that. That said, there isn't any issue with having old nodes that don't exist anymore inside a gestalt. So you can re run discovery now and see the new links, but the old stale links will just persist within the gestalt. I believe there's an issue handling revocation of cryptolinks. But that's not really a high priority at this moment. |
|
This also has a duplicate in linear, I'm closing it. |
|
I did some manual testing and sharing with an offline node results in
|
|
What does it result in? |
|
The command completes with no issue. |
CMCDragonkai
added
the
r&d:polykey:core activity 1
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
RPC Error Timeout when initiating vaults share secret command from CLI
To Reproduce
Expected behavior
identities listcommand. Feedback should be fixed here as well.Platform (please complete the following information)
Additional context
Notify maintainersbe
The text was updated successfully, but these errors were encountered: