test(sim): maker connext-client crash before taker order settlement #1758
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
|
After 2 attempts I was able to get them passing locally. The first 2 attempts failed with |
|
@sangaman please also try to run them locally to see if you run into similar issues? |
|
Can you give this a rebase and see if this still works? @LePremierHomme |
added 2 commits
September 30, 2020 14:51
# Conflicts: # test/simulation/custom-xud.patch
LePremierHomme
force-pushed
the
simtest_maker_connext_crash
branch
from
4448c5c
to
f41a0a7
Compare
|
The test case doesn't pass anymore, probably due to recent changes. As described, the test simulate the maker's connext client crash while taker is delaying the settlement. After the settlement, connext client is re-started and connection is verified. But then the recovery procedure doesn't kicking in, although its interval was adjusted to 2sec. Looks like there's an error connecting with LND-BTC, although its still alive, and later the invoice subscription is being deleted. The test fails because the maker's BTC funds aren't recovered, and the channel remains with active htlcs. @sangaman @erkarl any ideas? Maker xud log |
In those logs it does look like the Connext client gets shut down but it doesn't look like the send payment call to Connext actually fails - I don't see the logging statement from this line https://github.com/ExchangeUnion/xud/blob/master/lib/swaps/Swaps.ts#L1057 that I'd expect if a sendpayment call failed. I'm honestly not sure why that is - could it be that the client is down too briefly? If the call doesn't fail, it will get stuck waiting for a response from that call which appears to be what is happening. I have no explanation for why LND-BTC decides to fail after a while. Maybe it's hitting some timeout within the simulation test? As for why the invoice gets deleted, that's what we do when the invoice subscription to lnd gives us an error. |
|
Let's leave this open as draft as-is and give this another shot after switch to vector like you said @LePremierHomme |
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.
Implementing a new instability test scenario where, during a swap, the maker’s outgoing payment ETH swap client crashes while the taker is delaying his settlement.
I've implemented a similar one for LND, but it looks like that if the maker LND is crashing, the taker cannot settle.
The cannonical xud don't even reach that stage:
swapFailedpacket, so the taker fails the deal.If custom code is introduced, the taker still fails to settle the invoice (
UnexpectedClientError). This scenario also causes the channel to get closed.That's why I thought there's no point to keep this test, and I removed the test code (I still have it stashed in case we'll want it).