And one more fix to flaky tests#5467
Conversation
| block_on(pool.maintain(block_event(1))); | ||
| assert_eq!(pool.status().ready, 1); | ||
| block_on(notifier.next()); | ||
| block_on(notifier.next_blocking()); |
There was a problem hiding this comment.
What is the difference between next and next_blocking?
There was a problem hiding this comment.
next_blocking first clears the queue from all previous timer events, then starts to wait next one (same as clear() + next() before)
There was a problem hiding this comment.
Hmmm. If that is the case, what did change to the version before than? I don't see any difference.
There was a problem hiding this comment.
Now it clears events after maintain, so if during maintain the timer is fired, it is not handled before maintain is finished 😅
There was a problem hiding this comment.
Ahh, so we just than wait one iteration more?
There was a problem hiding this comment.
yes, one iteration that is guaranteed to be handled by timer handler
| [[package]] | ||
| name = "intervalier" | ||
| version = "0.3.0" | ||
| version = "0.3.1" |
There was a problem hiding this comment.
This should be required in the Cargo.toml
| block_on(pool.maintain(block_event(1))); | ||
| assert_eq!(pool.status().ready, 1); | ||
| block_on(notifier.next()); | ||
| block_on(notifier.next_blocking()); |
There was a problem hiding this comment.
Hmmm. If that is the case, what did change to the version before than? I don't see any difference.
| // maintenance is in background | ||
| block_on(notifier.next()); | ||
|
|
||
| let event = block_event_with_retracted(1, vec![retracted_hash]); |
There was a problem hiding this comment.
We lost one test case it seems?
There was a problem hiding this comment.
it was duplicated code that didn't add anything
3 participants
(testing timers is hard, but it should nail it)
Closes #5144