Guide de la version préliminaire · 0.1.0

Jobs durables et publication des éléments

Comprenez propriété des baux, validation des résultats, persistance avant acquittement et révisions des constats.

La référence de l’API est en anglais.

La base possède le travail accepté. Page rechargée, éditeur déconnecté ou worker privé de son bail ne font pas du navigateur le registre de ce qui s’est passé. État durable du job, transport de l’analyseur et éléments publiés restent distincts.

Identifier une commande avant exécution

Le dépôt de jobs lie une clé d’idempotence au client et au type de job. Répéter la même commande retourne le job existant ; réutiliser cette identité pour une autre commande crée un conflit. Le job possède aussi une identité externe stable de run, des documents de charge et de checkpoint bornés et une révision.

Les états sont queued, leased, running, cancelling, completed, failed et cancelled. Une soumission réussie signifie travail accepté, pas analyseur exécuté ni éléments complets disponibles.

claim_next_job exige PostgreSQL. Il verrouille les lignes admissibles sans attendre celle choisie par un autre worker et traite baux expirés et candidats à récupération. Les mutations vérifient sous verrou identifiant, worker, tentative, état permis et bail non expiré. Les heartbeats renouvellent cette propriété exacte. Un ancien propriétaire ne peut terminer le job simplement parce qu’il en détenait autrefois le bail.

Un échec réessayable remet le job en attente seulement dans ses limites de tentatives et de budget. Une nouvelle tentative ne prolonge pas indéfiniment une échéance de préparation. Voir dépôt de jobs et modèle de données.

Publier les éléments avant de permettre le nettoyage

L’analyseur scelle un résultat normalisé et expose manifeste et pages bornées. Leur seule disponibilité ne vaut pas publication durable pour le worker.

1. Valider le manifeste et lier run, digest de requête, digest de résultat, digest du manifeste d’artefacts et provenance dans le checkpoint durable.
2. Ouvrir une transaction PostgreSQL, verrouiller l’analyse parente et refuser la publication si elle possède déjà des constats ou des index d’artefacts. Lire chaque page bornée et vérifier ses identités, son curseur, ses ordinaux, ses nombres d’octets, ses hashes, ses valeurs canoniques, son ordre et ses empreintes uniques. Expurger et insérer les constats admis de cette page sans effectuer de commit.
3. Vérifier la concordance du flux complet et du résumé avec le manifeste. Admettre les artefacts attestés exacts, actualiser les révisions et enregistrer scanner_persisted=true dans cette même transaction.
4. Établir la validation de cette transaction avant l’ACK lié au run, à la requête et au résultat exacts.
5. Laisser l’analyseur retirer le résultat temporaire, puis finaliser analyse et contrôle. Un résultat persistant dont le nettoyage reste à réconcilier diffère d’éléments non publiés.

C’est une frontière d’insertion unique. Une tentative récupère son checkpoint validé ; elle ne remplace pas les constats existants ni n’efface la revue de l’opérateur. Une publication conflictuelle est refusée avec scan_evidence_conflict. La transaction de persistance fait autorité.

Si la transaction est annulée, les insertions partielles ne deviennent pas une référence. En cas d’issue incertaine, le worker réconcilie l’état durable avant nettoyage. Après persistance de scanner_persisted=true, la récupération se limite à l’ACK, sans relire ni réinsérer la collection. Un 404 de l’analyseur ne peut signifier « déjà nettoyé » que sur ce parcours déjà persistant. La récupération d’acquittement encadre cette exception.

Borner séparément transport temporaire et stockage

Le spool temporaire est un tmpfs privé. Ce n’est ni un stockage durable, ni un artefact téléchargeable, ni une sauvegarde. Les résultats non acquittés ne sont pas expulsés simplement pour libérer une place terminale ; la pression de capacité peut refuser du nouveau travail. La durée limite reste applicable. Un redémarrage perd registre local et secret de curseur et retire les anciens fichiers de spool reconnus.

Les curseurs lient processus, run, requête, résultat et position suivante. Ils ne sont pas réutilisables pour un autre résultat. Le registre des runs implémente ce contrat temporaire.

Conserver les éléments utiles sans publier les rapports bruts

Les constats gardent identité normalisée d’analyseur/règle, gravité, emplacement, message, extrait, empreinte et métadonnées bornées. Ils sont expurgés avant publication par l’analyseur puis avant insertion en base. L’expurgation reconnaît motifs connus et structures sensibles, sans garantir le retrait de tout secret possible.

La frontière d’artefacts admet des SBOM Syft CycloneDX JSON bornées et expurgées. Elle valide le chemin dédié avec des opérations no-follow, lie la provenance brute vers expurgée et indexe l’identité du contenu. Le téléchargement vérifie taille et digest contre l’index puis copie les octets vérifiés dans un stockage de réponse borné. Stdout, stderr, SARIF, JSONV2 et JSONL bruts ne sont pas des artefacts publiés.

Lisez expurgation de l’analyseur et admission et téléchargement. Ces contrôles réduisent l’exposition ; ils ne rendent pas sûre l’exécution de sources hostiles arbitraires.

Continuer le cycle de vie après publication

Un nouveau constat commence open, non supprimé des comptes, sans exemption, à la révision un. Les sept décisions sont open, needs_review, gate_exempt, accepted_risk, ignore, false_positive et fixed. Ce sont des états sélectionnables, pas un parcours linéaire obligatoire.

open et needs_review participent aux comptes du contrôle. gate_exempt et accepted_risk restent non supprimés mais n’y comptent pas. ignore, false_positive et fixed suppriment le constat des comptes. Les cinq exclusions exigent une raison non vide. Chaque changement vérifie la révision attendue, actualise les métadonnées de revue, le résumé des constats et l’évaluation du contrôle.

Marquer fixed n’inspecte pas un fichier modifié. Une nouvelle analyse produit de nouveaux éléments et ouvre ses constats. Les correspondances analyseur/empreinte entre analyses du projet alimentent l’historique, sans hériter des décisions antérieures. Supprimer un constat retire sa ligne ; cette action distincte vérifie révision et jobs actifs.

Pages et détails sont liés aux révisions de collection pour empêcher une vue ancienne d’écraser une décision récente. Les champs Advisor restent séparés du cycle de vie. Le conseil ne supprime pas automatiquement un constat, n’accepte pas le risque et ne modifie pas le contrôle. Voir mutation du cycle de vie et parcours des constats.

Observer annulation et récupération comme des résultats

La demande d’annulation est persistée et peut gagner la course contre la fin normale. Les issues terminales restent terminales. Les opérations de cache refusent l’annulation pendant commit ou activation, lorsque la publication a franchi sa frontière protégée. Annuler ne défait pas une génération activée et ne rappelle pas des données Advisor déjà livrées.

Job terminé, analyse complète et contrôle réussi sont différents. Seuls des éléments complets atteignent l’évaluation normale ; les décisions sur les constats ne réparent pas la couverture. L’implémentation du contrôle conserve cette distinction.

Les jobs durables permettent la réconciliation après interruption. Ils ne qualifient pas toute récupération après crash ou sinistre. L’outil actuel de sauvegarde est expérimental, non atomique et désactivé sans consentement explicite à un test jetable. Suivez la récupération et préservez les identités exactes des éléments lors d’un échec.