TL;DR @tuxmain comment en es-tu venu à ajouter mock_babe_initialize
?
Dans la fonction mock run_to_block
des tests d’intégration du runtime gdev, tu as ajouté une fonction mock_babe_initialize
(dans time-based UD) et incrémenté manuellement les slot BABE (dans distance-oracle).
J’ai un problème lors de la mise à jour v0.9.42 : le current_epoch_start
n’est pas mis à jour, et donc les sessions sont incrémentées à chaque bloc (ShouldEndSession
). Et vu que tu as modifié plusieurs trucs dans cette fonction lié à BABE, je me dis que tu as peut-être une idée.
J’ai ajouté un test test_session_change
dans une branche hugo-test-session-change
qui passe bien sur master
, mais plus sur la mise à jour.
On dirait que Session::on_initialize(System::block_number());
est bien appelé, mais par on_new_session()
de BABE.
Il y a deux possibilités pour que enact_epoch_change
soit appelé :
on_new_session
(dans notre cas)trigger
deEpochChangeTrigger
si les autorités ne changent jamais
on_new_session
devrait être appelé dans rotate_session
de la pallet Session
elle même appelée dans on_initialize
. Si je résume :
on_initialize
deSession
rotate_session
deSession
on_new_session
deBabe
enact_epoch_change
deBabe
…
En attendant, j’ai ajouté un changement de session à ta fonction :
fn mock_babe_initialize(n: u32) {
let slot: sp_consensus_babe::Slot = (n as u64).into();
pallet_babe::CurrentSlot::<Runtime>::put(slot);
// force epoch change based on session
let session = Session::current_index() as u64;
pallet_babe::EpochIndex::<Runtime>::put(session);
}
Le problème de l’EpochIndex
est probablement le même que celui du CurrentSlot
qui est également modifié dans initialize
de Babe
.