Fix : Synchronisation de l'index des sources externes : bandeau figé + cycle intégral à chaque passe

[TiotBenjy]

Trois problèmes distincts, en 3 commits séparés et relisibles indépendamment. Le premier est un bug d'affichage ; les deux autres sont des optimisations de la synchronisation elle-même, mises au jour en investiguant le premier.

1. fix(ui) : bandeau de fraîcheur figé sur « jamais synchronisé »

Une source désactivée dans les paramètres est exclue de tous les jobs de sync, et n'obtient donc jamais de last_sync. Or le front calculait la fraîcheur par un Math.max() sur toutes les sources, où hoursSinceSync(null) vaut Infinity. Une seule source désactivée suffisait à afficher l'avertissement en permanence. Constaté avec des sources synchronisées avec succès 20 minutes plus tôt, sans qu'aucune action utilisateur puisse l'éteindre.

GET /import/sync-status ne renvoyant pas l'état d'activation, le front ne pouvait pas distinguer "désactivée" de "réellement en retard". Le champ enabled est désormais exposé, issu de la même fonction que le filtre de sync, et le calcul est extrait dans computeIndexStaleness().

2. perf(sync) : sauter les sources dont l'index amont n'a pas changé

Chaque cycle re-téléchargeait et re-parsait les 120 sources intégralement, y compris celles inchangées depuis des semaines, soit ~18 min par cycle complet.

Le hash de l'index publié en amont est désormais mémorisé après chaque ingestion réussie (table source_index_state, migration 0011) et comparé au cycle suivant. Empreinte égale signifie bit pour bit le même index qu'en base : on ne se fie ni à un horodatage ni à un ETag serveur.

Côté APT, InRelease est téléchargée et authentifiée avant Packages.gz, de sorte que le hash attendu est connu avant de lancer un téléchargement important.

Deux invariants rendent le saut sûr. L'empreinte est effacée avant toute réécriture et réécrite seulement après succès complet, de sorte qu'une ingestion interrompue ne laisse jamais une empreinte prétendant que la base est complète (critique côté RPM, où le DELETE est commité dès le premier batch). Et un saut n'a lieu que si la source a encore des lignes en base, ce qui protège d'une purge ou d'une restauration partielle. Une source sautée voit tout de même son last_sync rafraîchi.

Un paramètre force (défaut false) permet de réindexer inconditionnellement. Le bouton de resync d'une source précise l'utilise ; la sync globale reste incrémentale.

Chaîne de confiance

Elle est inchangée, et l'authentification a lieu à chaque cycle, y compris quand la source est sautée :

Format	Authentification de l'index	Empreinte comparée
APT	signature GPG d'InRelease, vérifiée à chaque passe	SHA256 de Packages déclaré par cet InRelease authentifié
RPM	signature de repomd.xml via repomd.xml.asc, quand le dépôt en publie une	SHA-256 de primary.xml déclaré par repomd.xml
APK	signature RSA de l'archive, vérifiée contre le trousseau Alpine local	SHA-256 de l'archive, Alpine ne publiant pas de manifeste de hash

Un saut n'intervient que si l'empreinte issue d'une source authentifiée est identique à celle d'un contenu déjà vérifié et ingéré. Lors d'une ingestion réelle, le hash attendu reste confronté aux octets reçus ; un test dédié vérifie qu'un Packages.gz falsifié est rejeté et jamais parsé.

Un seul écart mérite d'être signalé : sur un saut APK, la signature RSA n'est pas revérifiée, puisque rien n'est ingéré et que les octets sont par construction ceux dont la signature avait déjà été validée.

3. perf(sync) : lever la sérialisation des sources RPM (1 vers 4)

_CONCURRENCY["rpm"] valait 1, par crainte de la taille de primary.xml (jusqu'à 600 Mo décompressés). _stream_download_and_parse() parse pourtant en flux et vide l'arbre à chaque paquet : l'empreinte mémoire est bornée par le batch de 500 lignes, pas par la taille du fichier.

Avec 58 sources RPM en série et un débit mesuré à ~1 Mo/s côté miroirs, ce sémaphore constituait à lui seul le chemin critique d'un cycle, soit ~17 min sur ~18, tandis qu'APT et APK finissaient en 4 min en parallèle. Le profilage d'une source donne ~15 s de téléchargement, ~10 s de parsing, ~4 s d'insertion : la phase dominante étant réseau, le parallélisme recouvre directement les attentes.
La valeur retenue est 4 et non davantage, le parsing XML restant borné par le GIL.

Mesures

Synchronisation de fedora42-aarch64 (67 343 paquets), index amont inchangé entre les deux passes : 30,8 s puis 0,8 s.

Bandeau, rejoué sur données réelles : 120 sources, 1 désactivée, 119 suivies, aucune sans last_sync. Bandeau masqué.

Tests

Suite complète backend : 1480 passed, 3 skipped. Frontend : 50/50.

Ajouts : test_index_state_skip.py (16 cas sur les invariants du saut) et indexStaleness.test.js (6 cas sur le calcul du bandeau). Les mocks de test_package_index_apt_sync.py sont adaptés au découpage de la vérification APT, avec un cas supplémentaire sur le rejet d'un Packages.gz falsifié.

Les suites ont été exécutées sur l'état cumulé des trois commits, pas sur chacun isolément.

Migration et compatibilité

0011_source_index_state crée une table, sans toucher aux données existantes. Validée sur PostgreSQL 16 en upgrade, downgrade et re-upgrade. Appliquée automatiquement par entrypoint.sh au démarrage.

Les ajouts d'API sont additifs (champ enabled dans /import/sync-status, paramètre force optionnel) et les appelants existants sont inchangés.

source_index_state étant vide au départ, le premier cycle après mise à jour reste une synchronisation intégrale ; le gain intervient à partir du second.

---

J'ai lu et j'accepte le CLA de repod v1.0 (CLA.md)