Anleitung zur Quellcode-Vorschau · 0.1.0
Jobs bis zum bestätigten Ergebnis verfolgen
Lies echten Fortschritt, unterscheide Warten von Fehlern und kläre Abbruch, Wiederholungen und unsichere Befehle ohne doppelte Arbeit.
Die API-Referenz ist auf Englisch.
Öffne die zuständige Aufgabe
Scans, Advisor-Prüfungen und Scannerwartung laufen als Jobs. Öffne Jobs in der Weboberfläche, finde die gestartete Aufgabe und nutze ihren Fortschritt, Ergebnislink und verfügbare Aktionen. Gleiche Art, Projekt oder Operation und Jobidentität vor Abbruch oder Wiederholung ab.
Die kompakte Übersicht gruppiert Gesamtzahlen nach Status und Art. Suche und Filter begrenzen die Liste, ohne diese Gesamtzahlen zu ändern. So findest du eine Aufgabe, ohne eine gefilterte Liste mit der vollständigen Installationshistorie zu verwechseln.

Jobs speichert Fortschritt und Endergebnisse zur Verfolgung über Navigation und Wiederverbindung hinweg.
Vollständiges Bild öffnenBeim ersten Laden zeigt die Ansicht Loading job history und Striche für nicht verfügbare Zahlen. No jobs yet und Nullwerte erscheinen erst nach einem erfolgreichen leeren Abruf. History unavailable bedeutet einen fehlgeschlagenen Abruf. Nach erfolgreichem Laden erhält ein späterer Aktualisierungsfehler die Historie und meldet den Fehler. Nutze Refresh zum Abgleich mit dem gespeicherten Zustand.
Lies Status vor Laufzeit
| Status | Geschehen |
|---|---|
| Waiting | Der Job liegt sicher in der Warteschlange und wartet auf einen Worker. |
| Assigned | Ein Worker hat den Job übernommen. |
| Running | Der Worker führt die Operation aus. Lies die aktuelle Phase. |
| Cancelling | Abbruch wurde angefordert; die Bereinigung wird noch abgeglichen. |
| Completed | Der Job hat einen erfolgreichen Endzustand erfasst. Öffne das Ergebnis zur Einordnung. |
| Failed | Der Job hat einen Fehler erfasst. Lies Grund und aktuell zulässige Wiederherstellungsaktionen. |
| Cancelled | Der Job hat Abbruch erfasst. Prüfe erhaltene Ergebnisse und operationsspezifische Wirkungen. |
Ein abgeschlossener Scanjob bedeutet kein bestandenes Richtlinien-Gate. Eine abgeschlossene Cache-Ergebnisprüfung macht die ursprünglich fehlgeschlagene Vorbereitung nicht erfolgreich. Folge dem Ergebnislink zum betreffenden Scan, Anbieter oder Scannerdatenzustand.
Eine Wiederholung kann den ersten Startzeitpunkt eines früheren Versuchs behalten. Die angezeigte Zeit kann deshalb frühere Versuche und Wartezeiten dazwischen enthalten. Ein erneut eingereihter Job wartet auf einen Worker, auch wenn er eine ältere Heartbeat- oder Aktivitätsangabe hat.
Interpretiere tatsächlichen Fortschritt
Scannerdatenjobs zeigen aktuelle Updaterphase, Komponente und Position, letzte Aktivität und Bytefortschritt, wenn die Quelle einen Gesamtwert liefert. Verifikation und Aktivierung haben nicht immer messbare Gesamtwerte. Ein unbestimmter Indikator bedeutet aktive Arbeit ohne zuverlässigen Gesamtprozentsatz oder Fertigstellungsprognose.
Phasen wie Download, Kandidatendatenprüfung, Aktivierung und Speichern des Belegs gehören zu einer Vorbereitung. Sie erhalten nicht jeweils eine neue Gesamtablaufzeit. Neuladen, Worker-Neustart oder Wiederholung ausgegebener Arbeit setzt das gespeicherte Vorbereitungsbudget nicht zurück.
Bei Work processing unavailable bleiben eingereihte Jobs dauerhaft erhalten. Verwende im Produktcheckout den unterstützten Startbefehl:
make up
Warte auf Worker-Gesundheit und aktualisiere den bestehenden Job. Prüfe sichere Jobdetails und die Produktausgabe von make logs, wenn Aktivität veraltet bleibt. Entferne keinen Scanner und lege die Datenbank nicht neu an, um eine Fortschrittsanzeige gesund erscheinen zu lassen.
Fordere Abbruch an und warte auf Bereinigung
Verwende Cancel für den genauen Job, wenn verfügbar. Das Produkt speichert zuerst die Anfrage und wartet dann auf Prozessbereinigung und den abschließenden Beleg. Browser, Fortschrittspanel oder Editor zu schließen führt diese Aktion nicht aus.
Abbruch kann mit Fertigstellung konkurrieren. Bei Scannervorbereitung wird er an der Aktivierungs- oder Commit-Grenze unverfügbar und macht keine bereits aktivierte geprüfte Generation rückgängig. Bei entfernter Advisor-Arbeit holt er keine bereits empfangenen Inhalte zurück. Lies Endergebnis und aktuellen Ressourcenzustand, statt vollständiges Rückgängigmachen anzunehmen.
Bei einem Editorstapel mit mehreren Wurzeln lässt der Abbruch des aktuellen Jobs spätere Wurzeln ungestartet. Bereits gestartete Wurzeln behalten ihre Einzelergebnisse. Ein unklares Jobergebnis stoppt ebenfalls weitere Einreichungen, damit der Stapel nicht ohne bekanntes Ergebnis weiterläuft.
Wiederhole nur bei angebotenem Retry
Nutze Retry ausschließlich bei einem geeigneten Job im Endzustand, der diese Aktion anbietet. Ein Fehler kann stattdessen einen Sperrgrund oder eine andere Wiederherstellungsoperation haben. Reiche dieselbe Arbeit nicht erneut ein, solange ihr ursprünglicher Job wartet, läuft oder abgebrochen wird.
Eine Vorbereitung mit abgelaufener Frist erhält durch Wiederholung desselben Befehls keine zusätzliche Zeit. Prüfe ihr Ergebnis und starte eine neue ausdrückliche Vorbereitung, wenn der Ablauf sie anbietet. Retry verification prüft ein unverändertes Cache-Ziel; es lädt keine Ersatzbytes herunter und repariert keine ungültigen Daten.
Eine unklare Scannerveröffentlichung kann Check cache outcome anbieten. Dies startet einen separaten schreibgeschützten Job mit eigener Fünfzehn-Minuten-Grenze. Er kann keine Daten herunterladen, aktivieren, zurückrollen oder bereinigen. Die ursprüngliche Vorbereitung bleibt fehlgeschlagen, selbst wenn die Prüfung eine erfolgreiche Veröffentlichung feststellt. Aktuelle Scannerbereitschaft entscheidet weiterhin über einen Scanstart.
Kehre nach Verbindungsverlust zurück
Bewahre genaue Job- und Befehlsidentitäten auf, wenn die UI sie liefert. Öffne Jobs erneut und aktualisiere nach dem Wiederverbinden dieselbe Ressource. Eine fehlende aktive Zeile, ein Clienttimeout oder HTTP 202 belegt keinen Endzustand: 202 bedeutet angenommener Befehl.
API-Clients müssen außerdem den Idempotenzschlüssel erhalten, wenn die Operation ihn verlangt. Gültige Schlüssel enthalten 8 bis 160 ASCII-Buchstaben, Ziffern, Punkte, Unterstriche, Doppelpunkte oder Bindestriche und beginnen mit Buchstabe oder Ziffer. Ein Schlüssel bindet einen genauen Befehl; erneute Verwendung mit anderem Inhalt kann einen Konflikt auslösen.
Kläre nach einem Timeout den ursprünglichen Befehl, bevor du einen neuen Schlüssel erzeugst. Der Header ist auf bestimmten Befehlsrouten erforderlich, nicht bei jeder POST-Anfrage. Sammelaktionen für Befunde verlangen ihn für Triage, nicht für alle Lebenszyklusänderungen. Lies die genaue Operationsseite vor dem Erstellen einer Anfrage.
Weiter geht es mit Wiederherstellung für unklare Ergebnisse, Scannervorbereitung für Bereitschaft oder Jobs- und Nachweisarchitektur für das Zusammenspiel von Zulassung, Worker-Ausführung und veröffentlichten Nachweisen.