Increase limits for flaky offer tests #3091
Conversation
Payment splitting is randomized which can lead to flaky tests. Tests requiring MPP used `maxAttempts = 3` which which fails in a bit less than 1% of runs, increasing to `maxAttempts = 4` should reduce the failure rate to less than 1 per thousand. We also increase the timeout for propagating channel updates.
|
I'm surprised that MPP is the culprit here when we're trying to send a 125 000 sats payment through two channels of capacity 100 000 sat without any other payment in parallel...are we over-estimating the amount we can send (e.g. not correctly taking into account the commitment fees)? Is there something that we should fix at the MPP level to improve this or is it just because of test conditions? |
|
It was quite hard to reproduce the failure, the test for which I managed to reproduce it was "send blinded multi-part payment a->b->c (single channel a->b)" and the three payment attempts had failed. In that test, the payer has very little information: the problematic channel is one hop away (so no local balance information) and inside a blinded route (so no failure message returned) and it makes sense it would fail. We could certainly improve the MPP logic and I'll look into it but I don't think there is anything broken currently. |
Payment splitting is randomized which can lead to flaky tests. Tests requiring MPP used
maxAttempts = 3which fails in a bit less than 1% of runs, increasing tomaxAttempts = 4should reduce the failure rate to less than 1 per thousand.We also increase the timeout for propagating channel updates.