-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Fix flaky reputation change test #7550
Fix flaky reputation change test #7550
Conversation
@@ -471,7 +470,7 @@ fn delay_reputation_change() { | |||
let pool = sp_core::testing::TaskExecutor::new(); | |||
let (ctx, mut handle) = make_subsystem_context::<BitfieldDistributionMessage, _>(pool); | |||
let mut rng = dummy_rng(); | |||
let reputation_interval = Duration::from_millis(1); | |||
let reputation_interval = Duration::from_millis(100); |
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.
let reputation_interval = Duration::from_millis(100); | |
let reputation_interval = Duration::from_secs(1); |
Can we bump it even more?
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 don't see a point. It will increase the test time by a whole second. 100ms are already too much. Actual execution time, I think, is about 2ms.
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 don't suppose we could make it so that it doesn't require any timeout at all? By, for example, waiting for something that we know must happen instead of just waiting for a predefined amount of time.
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.
No, it's not just a timeout for tests. Here we determine a value to use in the subsystem.
polkadot/node/network/bitfield-distribution/src/lib.rs
Lines 206 to 213 in 1346281
loop { | |
select! { | |
_ = reputation_delay => { | |
state.reputation.send(ctx.sender()).await; | |
reputation_delay = new_reputation_delay(); | |
}, | |
message = ctx.recv().fuse() => { | |
let message = match message { |
Please mention the issue in your MR description so its possible to track it #7407 |
Co-authored-by: Oliver Tale-Yazdi <[email protected]>
Test |
bot rebase |
Rebased |
I think so, I rebased, and the failed test is gone. |
bot merge |
* Fix flaky reputation change test * Remove fixme Co-authored-by: Oliver Tale-Yazdi <[email protected]> --------- Co-authored-by: Oliver Tale-Yazdi <[email protected]> Co-authored-by: parity-processbot <>
Fixes #7407
That job requires more than 1ms to complete on cold cache, so reputation change triggers twice. I changed the interval significantly, same as in other test uses reputation change.
Could you please check if this works?