Fix flaky BABE test (#13199)

The `authoring_blocks` test of BABE was calculating the slot based on the timestamp it sometimes
failed in CI. The problem is that we combine all the notifications and authoring futures in one big
future. This one big future may first polls one authoring future to build a block. Then it polls all
notification futures again to import the block. Then some other authoring future is polled and
builds on the imported block using the same slot and making the import fail. The solution is that we
just artificially increase the slot to make the test work.
This commit is contained in:
Bastian Köcher
2023-01-21 20:00:24 +01:00
committed by GitHub
parent 64b37b301d
commit a8d7cda774
+13 -5
View File
@@ -432,6 +432,7 @@ async fn run_one_test(mutator: impl Fn(&mut TestHeader, Stage) + Send + Sync + '
.for_each(|_| future::ready(())),
);
let client_clone = client.clone();
babe_futures.push(
start_babe(BabeParams {
block_import: data.block_import.lock().take().expect("import set up during init"),
@@ -439,12 +440,19 @@ async fn run_one_test(mutator: impl Fn(&mut TestHeader, Stage) + Send + Sync + '
client,
env: environ,
sync_oracle: DummyOracle,
create_inherent_data_providers: Box::new(|_, _| async {
let slot = InherentDataProvider::from_timestamp_and_slot_duration(
Timestamp::current(),
SlotDuration::from_millis(SLOT_DURATION_MS),
create_inherent_data_providers: Box::new(move |parent, _| {
// Get the slot of the parent header and just increase this slot.
//
// Below we will running everything in one big future. If we would use
// time based slot, it can happen that on babe instance imports a block from
// another babe instance and then tries to build a block in the same slot making
// this test fail.
let parent_header = client_clone.header(parent).ok().flatten().unwrap();
let slot = Slot::from(
find_pre_digest::<TestBlock>(&parent_header).unwrap().slot() + 1,
);
Ok((slot,))
async move { Ok((InherentDataProvider::new(slot),)) }
}),
force_authoring: false,
backoff_authoring_blocks: Some(BackoffAuthoringOnFinalizedHeadLagging::default()),