-
Notifications
You must be signed in to change notification settings - Fork 210
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
fix(recoverytest): wait for next session before scanning session outcomes for pegins #5184
Conversation
ff2c7e8
to
b11a669
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.
Thanks for tackling! Looks good as-is, but feel free to address the feedback before merging if you think it simplifies the test.
I'm having trouble reproducing the bug locally, so I'd assume the self-hosted runner with higher loads is needed to repro.
// session outcome in our DB. If there ever is another problem here: wait for | ||
// fedimintd-0 specifically to acknowledge the session switch. In practice this | ||
// should be sufficiently synchronous though. | ||
wait_session_outcome(&client, last_tx_session).await?; |
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.
I think this test was previously using a different (incorrect?) approach to awaiting the session outcome by looping until
if outputs.len() >= fed_utxos_sats.len() {
break outputs.clone();
}
I haven'f fully considered how, but this might be a bug since the epochs method includes descriptors from spent outputs in addition to UTXOs so we might break too early in this loop.
Now that we're explicitly waiting for the session outcome I think we can get rid of the loop and just call the recoverytool with epochs once.
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.
I removed the loop, good catch!
8e2cddb
to
fe2b75b
Compare
For tracking MQ failure #5186 |
Oh shoot, the recoverytool failure showed up in the MQ
https://github.com/fedimint/fedimint/actions/runs/8911963925/job/24474385524#step:5:925 |
|
Uff, now that's weird … |
I'm still having trouble reproducing locally. Let's see if we can figure out more when it flakes again in CI #5192 edit: having trouble reproducing with the self-hosted runner now 😄 |
Maybe let's land and follow up if/when we spot it again? |
I'm ok with that, but not very satisfying :/ |
That's new. |
dev call: we thought this was a fix for #5182, but apparently not ... |
No description provided.