You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the user submits a transaction using a Ledger account for the first time, they are required to approve and submit a "reveal PK" transaction. Currently, it is not handled if the user rejects that transaction, and following rejection will immediately try to execute the original transaction, which shouldn't happen.
If user rejects a Reveal PK, it should break out of the flow, and reset, displaying the rejection response to the user
If an error occurs (such as if the device is locked), this should also break that flow correctly (it will currently break the flow, but clicking "Try Again" does not hit the reveal PK step again successfully, meaning if the following tx is attempted, it will fail on chain)
Look into handling errors such as when the App itself is not loaded and thus the JS client is unable to initialize. Take a look at the LedgerErrors enum, and compare the results of the status query in each of these cases so we can handle them appropriately
This may take a little bit of time to determine the best way to handle all potential Ledger states, and could potentially be improved across the board.
The text was updated successfully, but these errors were encountered:
jurevans
changed the title
[Bug] Ledger Reveal PK TX Rejection does not break flow
[Bug] Ledger Reveal PK TX Rejection/Error does not break flow
Aug 3, 2023
When the user submits a transaction using a Ledger account for the first time, they are required to approve and submit a "reveal PK" transaction. Currently, it is not handled if the user rejects that transaction, and following rejection will immediately try to execute the original transaction, which shouldn't happen.
LedgerErrors
enum, and compare the results of the status query in each of these cases so we can handle them appropriatelyThis may take a little bit of time to determine the best way to handle all potential Ledger states, and could potentially be improved across the board.
The text was updated successfully, but these errors were encountered: