Handle Results of waiting for timelocks to expire #705
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rishflab
force-pushed
the
cancel-result-fix
branch
from
8c18f05 to
ed722e2
Compare
rishflab
approved these changes
Aug 30, 2021
thomaseizinger
approved these changes
Aug 30, 2021
thomaseizinger
previously requested changes
Aug 30, 2021
|
@rishflab please take this one over |
rishflab
force-pushed
the
cancel-result-fix
branch
from
ed722e2 to
52f4e2f
Compare
|
bors r+ |
bors bot
added a commit
that referenced
this pull request
Aug 31, 2021
705: Handle Results of waiting for timelocks to expire r=rishflab a=da-kami Fixes an issue where the CLI is transitioning into a `CancelTimelockExpired` state but the timelock is actually not expired yet. This happened because watching for confirmations errored and the error was not handled but the same behaviour as reaching the cancel timelock height was applied. For now this PR will fail the execution in case of the block height watching logic failing. Eventually there should be a more resilient strategy that includes retries. Co-authored-by: Daniel Karzel <daniel@comit.network> Co-authored-by: rishflab <rishflab@hotmail.com>
|
Build failed: |
|
@rishflab one of the tests in bors failed. Could take this opportunity to fixup the commits now that we have to retrigger anyway. |
im on it. It was Monero again |
rishflab
force-pushed
the
cancel-result-fix
branch
4 times, most recently
from
c7480f8 to
8c0a827
Compare
Probably a failure when interacting with the electrum node to get script status updates
Bob was timing out if the encrypted signature could not be sent in 60 seconds. This behaviour is unnecessary because we are racing against the cancel timelock anyway. By timing out before this, we remove the opportunity for bob and alice to re-establish a connection.
rishflab
force-pushed
the
cancel-result-fix
branch
from
8c0a827 to
af50c65
Compare
|
Thanks for improving the commits! |
|
bors r+ |
rishflab
added a commit
that referenced
this pull request
Sep 2, 2021
We were not thorough enough in PR #705 and there were some remaining unhandled errors.
rishflab
added a commit
that referenced
this pull request
Sep 2, 2021
We were not thorough enough in PR #705 and there were some remaining unhandled errors.
rishflab
added a commit
that referenced
this pull request
Sep 2, 2021
We were not thorough enough in PR #705 and there were some remaining unhandled errors.
rishflab
added a commit
that referenced
this pull request
Sep 2, 2021
We were not thorough enough in PR #705 and there were some remaining unhandled errors.
rishflab
added a commit
that referenced
this pull request
Sep 2, 2021
We were not thorough enough in PR #705 and there were some remaining unhandled errors.
rishflab
added a commit
that referenced
this pull request
Sep 2, 2021
We were not thorough enough in PR #705 and there were some remaining unhandled errors. Co-authored-by: Daniel Karzel <daniel@comit.network>
This was referenced Sep 5, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes an issue where the CLI is transitioning into a
CancelTimelockExpiredstate but the timelock is actually not expired yet.This happened because watching for confirmations errored and the error was not handled but the same behaviour as reaching the cancel timelock height was applied.
For now this PR will fail the execution in case of the block height watching logic failing. Eventually there should be a more resilient strategy that includes retries.