Probablement une question triviale, mais comment un indexeur réagit aux forks ?
Je veux dire : autant un nœud Substrate stocke tous les forks en parallèle via la mécanique du Storage, autant pour un indexeur j’ai du mal à voir 
Je n’ai pas cherché, je pose la question pour gagner du temps.
Il me semble que Duniter émet un event en cas de résolution de fork, Squid ne fait qu’écouter cet event et appliquer les changements induits par cette résolution.
Mais je ne suis pas sûr c’est juste ce que j’ai toujours supposé, je ne trouve pas de doc sur ce sujet.
En fait il n’est pas question d’event. Squid ne fait que suivre le déroulé de la blockchain. Lorsque cette dernière résoud un fork, Squid le remarque de par le changement de hash de la fenêtre courante, et le considère comme tel, et remonte jusqu’au dernier bloc commun avec la chaine actuelle.
Est-ce que ça veut dire qu’il est capable de revenir à un état antérieur pour annuler un bloc ?
Je ne sais pas non plus à quel point Substrate est résilient à un fork : au bout de combien de temps deux réseaux qui ont été séparés n’arrivent plus à résoudre le fork si on les réunit.
oui il annules les changements, on le voit dans les logs.
De mémoire c’est la fenêtre de « canonicalisation » la limite. Je ne sais plus la fenêtre précise mais j’ai 1024 blocs en tête.
Squid utilise les layers postgres pour tous les blocs entre le dernier bloc finalisé par son noeud archive et le bloc head. Il commit la transaction du bloc quand il est finalisé. C’est pour ça qu’on voit ceci dans les logs de l’indexeur :
processor-1 | {"level":2,"time":1759777254148,"ns":"sqd:processor","msg":"1275805 / 1275805, rate: 0 blocks/sec, mapping: 46 blocks/sec, 139 items/sec, eta: 0s"}
processor-1 | {"level":2,"time":1759777254195,"ns":"sqd:processor","msg":"navigating a fork between 1275805#bb84d to 1275805#af9d9 with a common base 1275804#5809c"}
processor-1 | {"level":2,"time":1759777259148,"ns":"sqd:processor","msg":"1275805 / 1275805, rate: 0 blocks/sec, mapping: 41 blocks/sec, 124 items/sec, eta: 0s"}
processor-1 | {"level":2,"time":1759777260197,"ns":"sqd:processor","msg":"navigating a fork between 1275806#3c41b to 1275806#dd36c with a common base 1275805#af9d9"}
processor-1 | {"level":2,"time":1759777264148,"ns":"sqd:processor","msg":"1275806 / 1275806, rate: 0 blocks/sec, mapping: 54 blocks/sec, 163 items/sec, eta: 0s"}
navigating a fork between 1275805#bb84d to 1275805#af9d9 with a common base 1275804#5809c
navigating a fork between 1275806#3c41b to 1275806#dd36c with a common base 1275805#af9d9"
Et c’est une des raisons principales qui nous ont poussé à abandonner l’indexeur “maison” de manu pour un indexeur basé sur squid.
Ah c’est cool ça ! Mais quid des résultats quand un fork est en cours dans la fenêtre de finalisation ?
Pas sûr de comprendre la question. Les résultats d’une requête retournent les résultats de la branche courante. Si la branche courante change, les résultats changent. Ce qui est finalisé ne peut plus revenir en arrière par définition de grandpa.
Je parle côté Squid : étant donné qu’il existe des résultats non commités, comment sont remontés les résultats s’il existe au moins un fork ?
Exemple : balance de 10 côté branche principale, balance de 11 côté fork du fait qu’il existe un transfert dans cette dernière branche qui n’existe pas dans la branche principale.
Autant côté Substrate le problème est résolu par le Storage, autant côté Squid avec ses “layers” je me pose la question. Ces derniers ressemblent beaucoup à ce qui existe sur Duniter v1.
J’avais lu des choses au sujet de la gestion des “hot blocks” (blocs non finalisés), mais on dirait que ça a disparu : https://docs.devsquid.net/sdk/resources/basics/unfinalized-blocks/.
Quand je disais “commit” ce n’était pas précis, ça utilise plutôt le mécanisme d’isolation de postgresql : https://www.postgresql.org/docs/current/transaction-iso.html.
Et ça explique pourquoi l’indexeur devient très lent quand la finalisation est bloquée.