FOXA-1215 : le miroir compte ses rejeux par fonction distante #1007
No reviewers
Labels
No labels
montee-majeure
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
foXaCe/NuvioTV!1007
Loading…
Reference in a new issue
No description provided.
Delete branch "passe-20261018-113000-miroirparrpc"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Résumé
FOXA-1215 — le miroir compte ses rejeux par fonction distante.
0115c21b3FOXA-1215 : le miroir compte ses rejeux par fonction distanteMirrorJournalStateporteokByRpcetfailuresByRpc.MirrorDrainWorkertransmethead.rpcNameau succès, et l'échec est compté sur la fonction qui l'a porté.Pourquoi
FOXA-1215 — le journal du miroir ne comptait les réussites que GLOBALEMENT (
okCount) : il nepouvait pas dire QUELLE fonction distante réussissait, donc pas non plus laquelle n'était jamais
appelée. C'est la question même du mode double, et le tableau des manques de Host que le ticket
demande.
⚠ Les deux compteurs ne suivent pas la même règle, et c'est voulu.
failuresByRpcsuit ledédoublonnage de FOXA-1619 — un état inchangé est UN fait, pas mille échecs. Un compteur par
fonction qui réintroduirait le bruit que le compteur global refuse aurait appris la leçon de
travers ; le test le verrouille (100 réveils → 1).
Rétrocompatibilité : les champs sont
nullpar défaut dansCounters, donc un journal écrit avantse relit sans erreur, et son absence n'est pas transformée en zéros — un zéro se lirait « cette
fonction n'est jamais appelée », le contraire de la vérité quand le miroir est muet.
Ce qui a été mesuré
Banc joué, pas déclaré :
Porte jouée par la forge, pas sur le poste : « Porte / porte* » est le seul contexte qu'exige la
protection de
main, et la fusion attend son vert.Scope boundaries
Le relevé ne vit pas ici : il est dans le dépôt
backend(outils/relever_journal_miroir.py,PR #113), et c'est lui qui lit ces compteurs pour rendre le tableau par fonction distante.
Les deux copies — TV et mobile — changent ensemble : un format qui bougerait d'un seul côté
recréerait la divergence que FOXA-2959 vient de payer sur les tables de logos.
Le journal du miroir ne comptait les réussites que GLOBALEMENT (`okCount`) : il ne pouvait pas dire quelle fonction distante réussissait, donc pas non plus laquelle n'était jamais appelée — la question même du mode double, et le tableau des manques de Host que `FOXA-1215` demande. `MirrorJournalState` porte maintenant `okByRpc` et `failuresByRpc`, persistés dans l'en-tête du journal. `MirrorDrainWorker` transmet `head.rpcName` au succès, et `appendFailureLocked` compte l'échec sur la fonction qui l'a porté. ⚠ LES DEUX COMPTEURS NE SUIVENT PAS LA MÊME RÈGLE, ET C'EST VOULU. · `okByRpc` compte chaque réussite ; · `failuresByRpc` suit la règle de dédoublonnage de `FOXA-1619` — un état inchangé est UN fait, pas mille échecs. Il compte donc les mêmes échecs DISTINCTS que `failureCount`, pas les réveils du drainage. Un compteur par fonction qui réintroduirait le bruit que le compteur global refuse aurait appris la leçon de travers. RÉTROCOMPATIBILITÉ. Les deux champs sont `null` par défaut dans `Counters` — pas une carte vide : un journal écrit avant se relit sans erreur, et son absence n'est pas transformée en zéros. Un en-tête plus riche n'est jamais écrasé par un fichier plus pauvre. Tests : 6 de plus (23 en tout), dont le cas d'échec d'abord — une carte absente ne fabrique pas de compteurs, et le dédoublonnage vaut aussi par fonction. Banc : `./gradlew :app:testFullDebugUnitTest -Pnuvio.android.distribution=full --tests '*MirrorJournalTest*'` → BUILD SUCCESSFUL, 23 tests, 0 échec. Ce que ce commit ne fait pas : le relevé lui-même. Il vit dans le dépôt `backend` (`outils/relever_journal_miroir.py`, PR #113), et c'est lui qui lit ces compteurs.