Guida alla versione preliminare · 0.1.0

Seguire i job fino a un esito confermato

Leggi l’avanzamento reale, distingui attesa ed errore e riconcilia annullamenti, tentativi e comandi incerti senza duplicare il lavoro.

Il riferimento API è in inglese.

Apri l’attività responsabile del lavoro

Scansioni, revisioni Advisor e manutenzione degli scanner vengono eseguite come job. Apri Jobs, trova l’attività avviata e consulta avanzamento, risultato e azioni disponibili. Verifica tipo, progetto o operazione e identità del job prima di annullare o riprovare.

Il riepilogo compatto raggruppa i totali per stato e tipo. Ricerca e filtri restringono la lista senza cambiare quei totali. Puoi così trovare un’attività senza confondere la lista filtrata con l’intera cronologia dell’installazione.

Al primo caricamento compaiono Loading job history e trattini per i conteggi non disponibili. No jobs yet e gli zeri appaiono solo dopo una lettura vuota riuscita. History unavailable indica un errore di lettura. Dopo un caricamento riuscito, un aggiornamento fallito conserva la cronologia e mostra l’errore; usa Refresh per riconciliarla con lo stato persistente.

Leggi lo stato prima del tempo trascorso

Un job di scansione completato non implica un gate superato. Un controllo dell’esito della cache completato non trasforma la preparazione originale fallita in un job riuscito. Segui il link a scansione, provider o stato dei dati pertinente.

Un nuovo tentativo può mantenere l’ora del primo avvio precedente. Il tempo mostrato può includere tentativi precedenti e attese intermedie. Un tentativo in coda attende un worker anche con un heartbeat o un’attività precedenti.

Interpreta l’avanzamento effettivo

I job dei dati mostrano fase, componente e posizione correnti dell’updater, ultima attività e byte quando la fonte fornisce un totale. Verifica e attivazione non hanno sempre totali misurabili. Un indicatore indeterminato significa attività senza percentuale complessiva o stima affidabili.

Download, verifica dei dati candidati, attivazione e salvataggio della ricevuta sono parti di una preparazione. Non ricevono ciascuna una nuova scadenza generale. Ricaricare, riavviare un worker o ritentare lavoro già emesso non azzera il budget persistente.

Se compare Work processing unavailable, i job in coda rimangono persistenti. Dalla copia del prodotto, usa il comando di avvio supportato:

make up

Attendi lo stato sano del worker, poi aggiorna il job esistente. Se l’attività resta obsoleta, esamina i dettagli sicuri e l’output di make logs. Non rimuovere uno scanner o ricreare il database per far sembrare sano un indicatore.

Chiedi l’annullamento e attendi la pulizia

Usa Cancel sul job esatto quando disponibile. Il prodotto registra prima la richiesta, poi attende pulizia dei processi e ricevuta finale. Chiudere browser, pannello o editor non esegue questa azione.

Annullamento e completamento possono concorrere. Nella preparazione, l’annullamento diventa indisponibile al confine di attivazione o commit e non può annullare una generazione verificata già attiva. In Advisor remoto non richiama contenuti già ricevuti. Leggi esito finale e stato corrente senza presumere che tutti gli effetti siano stati invertiti.

In un lotto multiradice dell’editor, annullare il job corrente lascia non avviate le radici successive. Ogni radice già avviata mantiene il proprio risultato. Un esito incerto ferma anche gli invii successivi perché il lotto non proceda oltre un risultato mancante.

Riprova soltanto quando il job lo offre

Usa Retry solo su un job finale idoneo che espone l’azione. Un errore può invece avere un motivo di blocco o un altro recupero. Non inviare lo stesso lavoro mentre l’originale attende, viene eseguito o annullato.

Una preparazione con scadenza emessa già trascorsa non ottiene tempo ripetendo il comando. Esamina l’esito, poi avvia una nuova preparazione esplicita quando il flusso lo offre. Retry verification controlla una destinazione cache invariata; non scarica byte sostitutivi e non ripara dati invalidi.

Una pubblicazione incerta può offrire Check cache outcome. Avvia un job separato in sola lettura con un limite proprio di quindici minuti. Non scarica, attiva, ripristina o elimina dati. La preparazione originale resta fallita anche se il controllo conferma la pubblicazione riuscita. La disponibilità attuale degli scanner determina comunque se può partire una scansione.

Riprendi dopo una disconnessione

Conserva le identità esatte di job e comando quando fornite. Riapri Jobs e aggiorna la stessa risorsa dopo la riconnessione. Una riga attiva mancante, un timeout client o HTTP 202 non provano un esito finale: 202 significa comando accettato.

I client API devono conservare anche la chiave d’idempotenza dove richiesta. Accetta da 8 a 160 caratteri ASCII: lettere, cifre, punti, underscore, due punti o trattini, iniziando con lettera o cifra. Una chiave lega un comando esatto; riutilizzarla con contenuto diverso può produrre conflitto.

Dopo un timeout, riconcilia il comando originale prima di creare una nuova chiave. L’header è richiesto da route specifiche, non da ogni POST. Le azioni in blocco sui rilievi lo richiedono per il triage, non per ogni modifica del ciclo di vita. Consulta la pagina dell’operazione esatta prima della richiesta.

Continua con il recupero per esiti incerti, la preparazione degli scanner per la disponibilità o l’architettura di job ed evidenze per il rapporto tra ammissione, esecuzione e pubblicazione.