Guide de la version préliminaire · 0.1.0

Suivre les jobs jusqu’à un résultat confirmé

Lisez la progression réelle, distinguez attente et échec, et réconciliez annulations, reprises et commandes incertaines sans dupliquer le travail.

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

Ouvrir la tâche responsable du travail

Analyses, revues Advisor et maintenance des analyseurs s’exécutent comme jobs. Ouvrez Jobs, trouvez la tâche lancée puis consultez progression, résultat et actions proposées. Vérifiez type, projet ou opération et identité du job avant annulation ou reprise.

Le résumé compact regroupe les totaux par état et type. Recherche et filtres réduisent la liste sans changer ces totaux. Ils permettent de trouver une tâche sans confondre la liste filtrée avec tout l’historique de l’installation.

Au premier chargement, Loading job history apparaît et les comptes indisponibles sont des tirets. No jobs yet et les zéros n’apparaissent qu’après une lecture vide réussie. History unavailable indique un échec. Après un chargement réussi, une actualisation échouée conserve l’historique et affiche l’erreur ; utilisez Refresh pour le réconcilier avec l’état persisté.

Lire l’état avant la durée

Un job d’analyse terminé n’implique pas un contrôle réussi. Une vérification de publication du cache terminée ne transforme pas la préparation initiale échouée en job réussi. Suivez le lien vers l’analyse, le fournisseur ou l’état des données concerné.

Une reprise peut conserver l’heure du premier démarrage antérieur. La durée affichée peut donc inclure les tentatives précédentes et leurs attentes. Une reprise en file attend un worker même si elle affiche un ancien heartbeat ou une ancienne activité.

Interpréter la progression réelle

Les jobs de données montrent étape, composant et position actuels de l’updater, dernière activité et progression en octets lorsque la source fournit un total. Vérification et activation n’ont pas toujours de total mesurable. Un indicateur indéterminé signifie une activité sans pourcentage global ni estimation fiables.

Téléchargement, vérification des données candidates, activation et enregistrement du reçu sont différentes parties d’une préparation. Chacune n’obtient pas un nouveau délai global. Rechargement, redémarrage d’un worker ou reprise d’un travail émis ne réinitialisent pas le budget persisté.

Si Work processing unavailable apparaît, les jobs en file restent durables. Depuis la copie du produit, utilisez la commande de démarrage prise en charge :

make up

Attendez la bonne santé du worker puis actualisez le job existant. Si l’activité reste ancienne, examinez les détails sûrs et la sortie de make logs. Ne supprimez pas un analyseur et ne recréez pas la base pour embellir un indicateur.

Demander l’annulation et attendre le nettoyage

Utilisez Cancel sur le job exact lorsque l’action est proposée. Le produit persiste d’abord la demande puis attend le nettoyage des processus et le reçu final. Fermer navigateur, panneau ou éditeur n’exécute pas cette action.

L’annulation peut arriver en même temps que la fin. En préparation, elle devient indisponible à la frontière d’activation ou de commit et ne peut défaire une génération vérifiée déjà activée. Pour Advisor distant, elle ne rappelle pas le contenu reçu. Lisez le résultat final et l’état actuel sans supposer tous les effets inversés.

Dans un lot multiracine de l’éditeur, annuler le job actuel laisse les racines suivantes non démarrées. Chaque racine déjà lancée conserve son résultat. Une issue incertaine arrête aussi les envois suivants pour ne pas dépasser un résultat manquant.

Reprendre seulement lorsque le job le propose

Utilisez Retry uniquement sur un job final admissible qui expose l’action. Un échec peut présenter un blocage ou une autre récupération. Ne soumettez pas le même travail tant que l’original attend, s’exécute ou s’annule.

Une préparation au délai émis expiré ne gagne pas de temps en rejouant la commande. Examinez l’issue puis lancez une nouvelle préparation explicite lorsque proposée. Retry verification vérifie une cible de cache inchangée ; il ne télécharge aucun octet de remplacement et ne répare pas de données invalides.

Une publication incertaine peut proposer Check cache outcome. Cela lance un job distinct en lecture seule, limité à quinze minutes. Il ne peut télécharger, activer, restaurer ni purger des données. La préparation initiale reste échouée même si la vérification confirme la publication. La disponibilité actuelle des analyseurs détermine toujours si une analyse peut démarrer.

Rejoindre le travail après une déconnexion

Conservez les identités exactes du job et de la commande lorsqu’elles sont fournies. Rouvrez Jobs et actualisez la même ressource après reconnexion. Une ligne active absente, un timeout client ou HTTP 202 ne prouve pas une issue finale : 202 signifie commande acceptée.

Les clients API doivent aussi conserver la clé d’idempotence lorsqu’elle est requise. Les clés comportent de 8 à 160 caractères ASCII : lettres, chiffres, points, tirets bas, deux-points ou tirets, en commençant par une lettre ou un chiffre. Une clé lie une commande exacte ; un contenu différent peut produire un conflit.

Après un timeout, réconciliez la commande initiale avant de créer une autre clé. L’en-tête concerne certaines routes, pas tous les POST. Les actions groupées sur les constats l’exigent pour le triage, pas pour tout changement de cycle de vie. Consultez la page d’opération exacte avant de construire la requête.

Poursuivez avec la récupération pour les issues incertaines, la préparation des analyseurs pour leur disponibilité ou l’architecture des jobs et éléments persistants pour relier admission, exécution et publication.