WIP: sync print 1 block apply when no blocks applied
Faux : un chunk pour les blocs de 0 à 249, et un seul bloc dans le chunk n°2
Non le bloc n°0 compte, donc si j'ai 250 blocs a sync, ça va du n°0 au n°249 = un seul chunk. En fait j'avais pensé la formule pour une sync initiale sans blockchain. Et du coup
current_blockstamp.idvaut zéro alors qu'on a zéro block, il devrait donc valoir -1 ou None mais du coup on ne pourrait plus utiliser un u32. Il faut remettre le +1 dans les cas ou le nœud n'a aucun block (cad quandcurrent_blockstamp == Blockstamp::default()).En fait, c'est même pire que ça, ça dépend de la valeur de
current_blockstamp. Par exemple si je suis au bloc 200 et que le target est 550 j'ai 3 chunks a récupérer : les chunks 0, 1 et 2 ! En fait il faudrait étudier comment est utilisé la variablecount_chunkspour voir ce qui est exactement attendu actuellement. Mais en tout les cas a terme un récupérera des chunks fixes donc faudra changer la formule de calcul.Je regarderai ça dés que possible, mais probablement que lundi car je suis en déplacement ce WE :)
D'accord, dans ce cas, il faut juste regarder sur combien de chunks on est. Est-ce qu'il ne vaudrait pas mieux faire une fonction qui retourne un itérable qui permet de parcourir les blocs sans se soucier des chunks ? La fonction s'occuperait elle même de lire les chunks nécessaire pour fournir l'itérateur demandé? Et cet itérable pourrait être produit sois par une fonction de synchronisation locale sois par une fonction de synchronisation distante.
Je regarderai ça dés que possible, mais probablement que lundi car je suis en déplacement ce WE :)
Idem, ce weekend, je pars avec Lucie
-
D'accord, dans ce cas, il faut juste regarder sur combien de chunks on est.
Il faut surtout étudier comment est utilisé la variable
count_chunksactuellement pour s'assurer de ne pas produire de régression.Est-ce qu'il ne vaudrait pas mieux faire une fonction qui retourne un itérable qui permet de parcourir les blocs sans se soucier des chunks ? La fonction s'occuperait elle même de lire les chunks nécessaire pour fournir l'itérateur demandé?
On ne pourra pas faire ça car dans le cas d'une sync via le réseau on recevra les chunks en asynchrone et pas forcément dans l'ordre. C'est la fonction de récupération des chunks qui gèrera son cache pour fournir ensuite les blocs dans l'ordre a traver le channel Rust. La fonction de sync écoutera sur un channel rust pour recevoir les blocks, c'est déjà le comportement actuel dans une sous-partie de local_sync() donc c'est le choix de refactoring le plus pertinent par rapport a l'existant ;) En fait ce code que tu modifie sera déplacé dans la fonction qui récupère les blocs car cela dépens du target. Il faudra 2 channel entre les 2 (1 dans chaque sens). C'est le starter qui donnera les bon receiver et sender a chacun, c'est un refactoring un peu compliqué et sensible je préfèrerai le faire moi. Du coup pour cette MR reste iso avec l'existant stp :)
Edited by Éloïs
Tiens pour le coup je vois une faille que j'avais introduit qu'il faut corriger :)
Ici il faut vérifier que
target_blockstamp.id.0 >= current_blockstamp.id.0sinon on peut se prendre un panic implicite a l'éxécution (on manipule des entiers unsigned donc qui ne peuvent aps etre négatifs).Si je te le dit c'est que j'en suis certain oui, j'en ai déjà fait les frais, le Rust n'est pas le Julia ;) D'ailleurs c'est cohérent avec la logique de Rust => interdire les comportement "bizarres" => donc au lieu d'aboutir a des nombres très grands qui pourraient provoquer des comportements imprévisibles et difficiles a débuger, la ça panic et au moins on sait tout de suite ou est la cause.