New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Sapling] Try to recover corruption of notes cache during send operation #2027
[Sapling] Try to recover corruption of notes cache during send operation #2027
Conversation
bb35d0a
to
7e99d38
Compare
Locks updated. |
7e99d38
to
0dc0896
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
really nice and straightforward contingency plan while we search for the cause 👍.
ACK 0dc0896
also notify the UI so it's updated live.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haven't checked it with the corrupted/invalid wallet, pure code review, ACK 9c6bf2d.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have tested it with the corrupted wallet and all went well but have to say haven't seen any message of the added logging which is weird.
But well, it's an edge case scenario that we should discover the issue soon anyway (in testnet).
All good for me to go ahead with this one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 9c6bf2d
This is a contingency plan, in case of missing cached nullifier of a spent note in the wallet.
Since, during the spend, the wallet is unlocked, and we have the spending key, we can directly recover the nullifier from the note (provided that we have a valid cached witness) and fix the issue in the background, without requiring any user intervention.
If we don't have the witness, we can still provide a better log and error message in the gui, than a generic, and probably obscure