search

urbit / bridge

An application for interacting with Azimuth.
MIT License
96 stars 25 forks source link

Change Request: Add notice to user of potential delay generating L1 Keys #1033

Open rabsef-bicrym opened 2 years ago

rabsef-bicrym commented 2 years ago

Describe the bug I burned two rifts thinking that maybe I had somehow corrupted a keyfile on a ship I was breaching as the urbit runtime was telling me the key didn't match the public-key state. Waiting some 10 minutes allowed the third keyset I'd generated to be valid and boot the planet. This is an L1 planet - I believe that the delay may be accounted for by routing the traffic thru the rollup rather than directly to a node, but I am not sure. It, in any event, is a departure from prior behavior.

To Reproduce Steps to reproduce the behavior:

  1. Breach a ship (L1)
  2. Immediately attempt to boot from the generated keyfile

Expected behavior Either notify the user that they will need to wait or do not provide the keyfile until the network change has saturated and one can boot from it.

matildepark commented 2 years ago

Yes, I hit this too all the time — I have to tell people if they breach that it'll be about a half hour and it'll keep telling them they have the wrong keys but it's just that Azimuth now takes like a half hour to see what they did

jeremytunnell commented 2 years ago

IMO, using a timer like we do with invites is a better solution than yet more warnings and instructions.