Polling von Statusendpunkten: Wie Agenten ohne Schleifen warten

Ein Agent, der einen externen Job startet, darf nicht immer wieder fragen: «Sind wir schon da?», bis ein Provider, ein Budget oder ein Mensch aufgibt. Polling an einem Statusendpunkt braucht einen klaren Vertrag: Was gilt als Fortschritt? Wann darf die nächste Anfrage erfolgen? Wann endet das Warten, und wer entscheidet danach über das weitere Vorgehen?

Ich habe erlebt, wie scheinbar harmlose Statusprüfungen zu Hunderten von Aufrufen wurden, weil eine Job-ID gültig war, der Endpunkt weiterhin HTTP 200 zurückgab und niemand dem Agenten mitgeteilt hatte, dass «running» nach Ablauf einer Frist keine akzeptable Antwort mehr war. Die Lösung ist keine ausgeklügelte Zeitplanung. Warten muss als begrenzte Aktion mit Nachweisen und einem Eskalationsweg definiert werden.

Ein laufender Status erlaubt Warten, aber kein Handeln

Ein nichtterminaler Jobzustand erlaubt eine spätere weitere Prüfung. Er erlaubt dem Agenten nicht, das Ergebnis abzurufen, abhängige Arbeit zu starten, die ursprüngliche Übermittlung erneut zu versuchen oder seinen Handlungsspielraum zu erweitern.

Diese Unterscheidung ist wichtig, weil asynchrone APIs für jeden Zustand oft eine erfolgreiche HTTP-Antwort liefern. Eine Antwort wie diese zeigt, dass der Statusendpunkt funktioniert hat. Sie sagt nicht, dass der Job erfolgreich war.

{
  "job_id": "exp_71c",
  "state": "running",
  "updated_at": "2025-04-18T10:24:00Z"
}

Behandeln Sie das HTTP-Ergebnis und das Job-Ergebnis als zwei getrennte Tatsachen. Die erste beantwortet die Frage: «Hat der Provider auf diese Anfrage geantwortet?» Die zweite beantwortet: «Darf der Workflow fortgesetzt werden?» Teams vermischen beides ständig. Danach lädt ein Agent einen unvollständigen Export herunter oder veröffentlicht ein Ergebnis, das nie existiert hat.

Erstellen Sie für jede Provider-Integration eine kleine Zustandstabelle. Leiten Sie die Bedeutung nicht aus einem Feldnamen wie status ab. Provider verwenden dasselbe Wort für sehr unterschiedliche Abläufe. Eine brauchbare Tabelle enthält diese Kategorien:

• Wartende Zustände erlauben eine spätere Statusanfrage, etwa queued, running oder processing.
• Erfolgszustände erlauben die ausdrücklich benannte Folgeaktion, etwa das Abrufen einer Ergebnis-URL.
• Fehlerzustände beenden den Lauf und bewahren den Providerfehler auf.
• Stornierungs- und Ablaufzustände beenden den Lauf, ohne ihn erneut zu übermitteln, sofern ein Mensch dies nicht ausdrücklich verlangt.
• Unbekannte Zustände beenden den Lauf, weil eine Integration nicht sicher annehmen kann, dass paused, awaiting_review oder ein neu hinzugefügter Wert harmlos ist.

Prüfen Sie die Statusantwort außerdem auf Widersprüche. Ein Job mit dem Zustand succeeded, aber ohne den erforderlichen Ergebnisverweis, ist noch nicht bereit zur Verarbeitung. Ein Job, der nach seiner eigenen gemeldeten Ablaufzeit weiterhin running meldet, braucht eine Eskalation und nicht noch mehr Vertrauen in das Polling.

Bewahren Sie Job-ID, Provider-Kontokontext, Fingerabdruck der ursprünglichen Anfrage und die erwarteten terminalen Zustände gemeinsam auf. Verliert der Agent diese Verbindung, fragt er nach einem Neustart möglicherweise den falschen Job ab oder behandelt versehentlich einen Job aus einer früheren Anfrage als den aktuellen.

Feste Intervalle erzeugen gebündelten Druck

Ein festes Intervall sieht im Code ordentlich aus und verhält sich in einer Flotte schlecht. Wenn fünfzig Agenten ungefähr in derselben Minute Arbeit übermitteln und alle zehn Sekunden pollen, treffen die Anfragen meist in Gruppen beim Provider ein. Diese Gruppen bleiben auch nach einem kurzen Ausfall bestehen, weil jeder Agent nach derselben Uhr erneut versucht.

Verwenden Sie eine wachsende Verzögerung mit Jitter. Beginnen Sie nur dann mit einer kurzen Verzögerung, wenn der Provider normalerweise schnell fertig wird oder den Status sofort aktualisiert. Verlängern Sie die Wartezeit nach jeder ausstehenden Antwort, begrenzen Sie sie und variieren Sie die tatsächliche Verzögerung pro Lauf.

Ein praktischer Zeitplan kann nach dieser Regel funktionieren:

base_delay = 5 seconds
max_delay = 120 seconds
attempt = number of completed polls
raw_delay = min(max_delay, base_delay * 2^attempt)
actual_delay = random value between 50% and 100% of raw_delay

Der Zufallsbereich ist wichtig. Eine deterministische Folge von 5, 10, 20, 40 und 80 Sekunden verschiebt die Synchronisierung lediglich in größere Wellen. Vollständiger Jitter, bei dem der Zufallswert zwischen null und der Obergrenze liegen kann, funktioniert in manchen Systemen ebenfalls. Beim Job-Polling bevorzuge ich eine Untergrenze, weil ein Lauf, der wiederholt Verzögerungen nahe null auswählt, einem Sturm aus Wiederholungsanfragen ähnelt.

Wenden Sie keinen allgemeinen Backoff-Zeitplan an, ohne die Jobdauer zu berücksichtigen. Eine Dokumentkonvertierung, die normalerweise innerhalb einer Minute fertig ist, profitiert von frühen Prüfungen. Ein Batch-Export mit geschätzter Fertigstellungszeit sollte nicht alle paar Sekunden eine Statusanfrage erhalten, nur weil der Agent untätig wirkt.

Wenn die API ein Feld wie next_check_at, poll_after_seconds oder ein ähnliches Feld liefert, behandeln Sie es als Empfehlung des Providers. Prüfen Sie den Wert, bevor Sie ihn übernehmen. Lehnen Sie negative Werte, unrealistisch lange Wartezeiten über die Frist Ihres Vorgangs hinaus und nicht lesbare Zeitstempel ab. Der Agent kann bis zum angegebenen Zeitpunkt oder bis zu seiner eigenen Frist warten, je nachdem, was zuerst eintritt.

Eine Verzögerung ist kein Versprechen, dass der Agent genau in diesem Moment eine Anfrage stellt. Ein lokaler Prozess kann schlafen, neu starten, die Verbindung verlieren oder viel später fortgesetzt werden. Prüfen Sie beim Aufwachen zuerst, ob die Frist abgelaufen ist. Holen Sie verpasste Intervalle nicht nach, indem Sie mehrere Statusanfragen auf einmal senden.

Eine Frist und ein Anfragebudget erkennen unterschiedliche Fehler

Jeder Polling-Lauf braucht sowohl eine Frist nach Echtzeit als auch eine maximale Zahl von Statusanfragen. Für Transportfehler sollten Sie ein separates Limit hinzufügen, wenn der Provider entfernt oder unzuverlässig ist.

Eine Frist begrenzt, wie lange der Workflow ungeklärt bleiben darf. Sie verhindert, dass ein Agent eine veraltete Aufgabe über ein Wochenende hinweg am Leben hält, nur weil die API weiterhin queued meldet. Legen Sie die Frist anhand der geschäftlichen Folgen einer Verzögerung, der dokumentierten Aufbewahrungsdauer des Providers und des Zeitpunkts fest, ab dem ein Mensch entscheiden sollte. Leiten Sie sie nicht nur aus der durchschnittlichen Laufzeit ab. Durchschnittswerte verbergen die Jobs, die stecken bleiben.

Ein Anfragebudget begrenzt den Druck, den der Agent auf den Provider und die verwendeten Zugangsdaten ausübt. Es erkennt einen Fehler bei der Zeitplanung, selbst wenn die Zeit nur langsam vergeht, und begrenzt Kosten, wenn eine API Aufrufe abrechnet. Das Budget sollte auch Statusaufrufe nach unklaren Netzwerkzuständen enthalten. Wenn Sie diese Aufrufe nicht anrechnen, kann ein Agent das Kontingent des Providers aufbrauchen und sich dabei einreden, er habe nur wenige Versuche unternommen.

Ein Fehlerbudget hat eine engere Aufgabe. Zählen Sie abgelehnte Verbindungen, DNS-Fehler, TLS-Fehler und 5xx-Antworten, die den Agenten daran hindern, den Jobzustand zu erfahren. Eine einzelne Zeitüberschreitung beweist nicht, dass der Job fehlgeschlagen ist. Eine Stunde lang dieselbe fehlgeschlagene Anfrage zu wiederholen, beweist ebenfalls keine Geduld.

Verwenden Sie einen dauerhaft gespeicherten Vorgangsdatensatz wie diesen, der vor der ersten Prüfung angelegt wird:

{
  "operation_id": "report-export-2025-04-18-01",
  "provider_job_id": "exp_71c",
  "started_at": "2025-04-18T10:20:00Z",
  "deadline_at": "2025-04-18T11:00:00Z",
  "max_status_requests": 12,
  "max_transport_failures": 3,
  "status_requests_used": 0,
  "transport_failures_used": 0,
  "last_known_state": "queued"
}

Die Werte sind Beispiele und keine Standardwerte für jeden Provider. Zwölf Prüfungen in vierzig Minuten können für einen langsamen Export passen. Für einen Vorgang, der normalerweise in drei Sekunden fertig ist, wäre das unsinnig, und für einen Job, den der Provider nur alle fünfzehn Minuten prüfen lassen möchte, wäre es gefährlich.

Prüfen Sie die Frist vor einer Anfrage und nicht erst danach. Sonst kann ein spät aufwachender Prozess einen nicht autorisierten zusätzlichen Aufruf ausführen. Prüfen Sie das Anfragebudget unmittelbar vor der Planung und erhöhen Sie den Zähler unmittelbar vor der Übertragung. Diese Reihenfolge ist wichtig, wenn ein Prozess zwischen Planung und Versand abstürzt. Eine gelegentlich ungenutzte Reservierung ist besser als eine unsichtbare zusätzliche Anfrage.

Stop-Bedingungen müssen ausführbar sein

«Stoppen, wenn es zu lange dauert» ist eine Notiz für einen Menschen, aber keine Bedingung, die ein Agent durchsetzen kann. Definieren Sie Stop-Bedingungen als Prädikate über den aktuellen Datensatz und die Antwort.

Stoppen Sie erfolgreich nur dann, wenn der Provider einen zugelassenen terminalen Erfolgszustand meldet und jedes für die nächste Aktion benötigte Feld die Validierung besteht. Wenn die nächste Aktion ein Artefakt herunterlädt, prüfen Sie den Artefaktverweis, bevor Sie den Erfolg erklären. Wenn die nächste Aktion ein anderes System betrifft, speichern Sie die terminale Antwort, bevor Sie diese Aktion ausführen.

Beenden Sie den Lauf mit einem Fehler, wenn der Provider einen terminalen Fehler meldet, die Antwort nicht geparst werden kann oder ein Zustand außerhalb der Allowlist liegt. Der Umgang mit unbekannten Zuständen verdient dieselbe Aufmerksamkeit wie eine verweigerte Autorisierung. Ein Provider kann ohne Vorwarnung einen Zustand wie needs_payment, manual_review oder blocked hinzufügen. Wenn Sie raten, dass er «warten» bedeutet, wird aus einer Änderung beim Provider auf Ihrer Seite eine Endlosschleife.

Beenden Sie den Lauf wegen Zeitüberschreitung, sobald die Frist erreicht ist, auch wenn sich der Status gerade geändert hat. Der Agent sollte den zuletzt beobachteten Zustand melden, darf sich aber keine weitere vollständige Wartezeit geben, nur weil er etwas sieht, das nach Fortschritt aussieht. Wenn eine längere Wartezeit akzeptabel ist, muss dies eine neue Autorisierungsentscheidung mit einer neuen Frist sein.

Beenden Sie den Lauf wegen erschöpften Budgets, wenn die nächste Statusanfrage die erlaubte Anzahl überschreiten würde. Setzen Sie den Zähler nicht zurück, nur weil der Agent neu gestartet wurde, die Sitzung gewechselt hat oder eine neue Eingabe erhalten hat. Für den Provider gibt es einen Aufrufer und einen Job, nicht Ihre internen Prozessgrenzen.

Beenden Sie den Lauf nach einer Zeitüberschreitung einer Statusanfrage mit unklarer Zustellung, sobald das Fehlerbudget erschöpft ist. Der Agent kann nicht wissen, ob der Provider die Anfrage erhalten hat. Statusanfragen sollten sich jedoch sicher wiederholen lassen. Wenn der Endpunkt bei jedem GET den Zustand ändert, Geld berechnet oder ein Artefakt aktualisiert, ist er im operativen Sinn kein Statusendpunkt. Behandeln Sie ihn als Aktion und verlangen Sie strengere Kontrollen.

Hier machen Teams einen kostspieligen Fehler: Sie nehmen an, GET sei harmlos. HTTP definiert GET semantisch als sichere Methode. Das bedeutet, dass der Client keine Zustandsänderung angefordert hat. Diese Zusage muss der Server einhalten. Sie ist keine magische Eigenschaft einer URL. Prüfen Sie das Verhalten des Providers mit einem Testkonto und anhand seiner Dokumentation, bevor Sie einen Aufruf als reine Beobachtung einstufen.

Beachten Sie die Protokollsignale der Provider

HTTP bietet einige Signale, die das Polling eines Agenten sofort ändern sollten. Sie zu ignorieren, weil die Schleife ihren eigenen Timer hat, ist unhöflich gegenüber dem Provider und macht die Wiederherstellung meist langsamer.

RFC 9110 definiert Retry-After als Hinweis auf die Mindestzeit, die ein Client vor einer Folgeanfrage warten sollte. Das Feld kann eine Verzögerung in Sekunden oder ein HTTP-Datum enthalten. Parsen Sie beide Formen. Erhält eine Statusanfrage 503 mit Retry-After: 120, verwenden Sie nicht Ihr übliches Backoff von dreißig Sekunden und versuchen Sie es zu früh erneut. Warten Sie mindestens zwei Minuten, sofern die Frist des Vorgangs dies erlaubt.

RFC 6585 definiert HTTP 429, Too Many Requests, und sieht vor, dass eine Antwort Retry-After enthalten kann. Dadurch können Provider den Header weglassen, weshalb der Agent weiterhin eigenes Backoff braucht. Eine 429-Antwort ohne Hinweis sollte die Verzögerung deutlich erhöhen und auf das von Ihnen definierte Fehler- oder Rate-Limit-Budget angerechnet werden. Ein Lauf, der weiterhin 429 erhält, sollte eskaliert werden. Er sollte seinen Timer nicht unbegrenzt verlängern.

Bei 202 Accepted prüfen Sie Antworttext und Header auf eine Location, eine Job-ID und die angegebene Statusressource. Konstruieren Sie keine erratene URL aus dem Übermittlungsendpunkt. Manche Provider verwenden eine Ergebnisadresse, andere eine Statusadresse, und manche liefern die endgültige Darstellung später. Halten Sie sich an den dokumentierten Vertrag.

Bei 404 sollten Sie nicht immer davon ausgehen, dass der Job nie existiert hat. Ein gerade übermittelter Job kann wegen eventual consistency vorübergehend nicht gefunden werden, und ein abgeschlossener Job kann nach Ablauf der Aufbewahrungsfrist verschwinden. Der ursprüngliche Vertrag des Providers entscheidet, welche Erklärung plausibel ist. Erklärt das dokumentierte Verhalten den Fall nicht, stufen Sie ihn als Integrationsfehler ein und eskalieren Sie mit Job-ID und Zeitstempeln.

Bei 401 oder 403 stoppen Sie das Polling. Autorisierungsfehler mit denselben Zugangsdaten zu wiederholen, erzeugt nur mehr Lärm und kann Schutzmaßnahmen beim Provider auslösen. Der Mensch muss Zugriff, Rotation der Zugangsdaten, Kontoberechtigungen oder die Gateway-Konfiguration prüfen. Die Polling-Aktion ist beendet.

Für 5xx-Antworten und Netzwerkfehler verwenden Sie das Transportfehlerbudget. Bewahren Sie Antwortcode, Anfragezeitpunkt und jede Provider-Anfrage-ID auf. Diese Angaben sind wichtig, wenn Support oder eine zuständige Person eine verlorene Antwort von einem fehlgeschlagenen Job unterscheiden muss.

Eine Eskalation sollte eine Entscheidung ermöglichen, nicht ein Log ausschütten

Ein Agent braucht einen festgelegten Punkt, an dem er das Warten beendet und die Situation an einen Menschen oder einen anderen ausdrücklich autorisierten Workflow übergibt. Eine Eskalation ist keine dekorative Benachrichtigung, die erst erscheint, nachdem der Agent jede Möglichkeit erneut versucht hat.

Machen Sie den Eskalationsgrund maschinenlesbar. Verwenden Sie Kategorien wie deadline_exceeded, request_budget_exhausted, rate_limited, unknown_state, authorization_denied oder provider_failure. Jede Kategorie sollte die zulässige nächste Aktion bestimmen. Ein Mensch kann bei unknown_state eine vorübergehende Pause freigeben, während jemand Änderungen beim Provider prüft. Bei authorization_denied sollte er keine weitere identische Anfrage freigeben.

Die Eskalationsnachricht sollte genügend Kontext für eine Entscheidung enthalten, ohne Geheimnisse preiszugeben:

External job needs a decision
Operation: report-export-2025-04-18-01
Provider job: exp_71c
Last state: running
Elapsed time: 40 minutes
Status requests: 12 of 12
Last HTTP result: 200 at 10:58 UTC
Stopped because: request_budget_exhausted
Safe options: extend waiting once, cancel at provider, inspect provider console

Formulieren Sie die Auswahl nicht als «Fortfahren?». Das lädt dazu ein, eine unbegrenzte Schleife freizugeben. Bieten Sie begrenzte Optionen an. «Um fünfzehn Minuten mit vier weiteren Prüfungen verlängern» nennt den Aufwand und schafft ein neues Limit. «Beim Provider stornieren» sollte nur erscheinen, wenn die Integration eine dokumentierte Stornierungsaktion bietet und die zuständige Person ihre Folgen versteht.

Eskalieren Sie früher, wenn das spätere Ergebnis nur kurz nützlich wäre. Eine Bereitstellungsprüfung, die erst nach Ende des Bereitstellungsfensters eintrifft, verdient möglicherweise kein weiteres Polling. Der Export eines Steuerdokuments kann es dagegen wert sein, einen Provider-Ausfall abzuwarten. Der technische Zustand allein kann diese Priorität nicht bestimmen. Wenn sie sich unterscheidet, müssen Sie die geschäftliche Workflow-Frist getrennt von der Job-Frist des Providers erfassen.

Vermeiden Sie eine automatische erneute Übermittlung nach einer Zeitüberschreitung, sofern der Provider keine Idempotenz unterstützt und Sie das Idempotenz-Token dauerhaft speichern. Ein Fehler beim Status-Polling beweist nicht, dass der ursprüngliche Job fehlgeschlagen ist. Eine erneute Übermittlung kann doppelte Rechnungen, E-Mails, Bereitstellungen oder konkurrierende Exporte erzeugen. Bis zum Aufräumen nennen Menschen so etwas «Selbstheilung».

Ein Polling-Controller braucht dauerhaften Zustand und einen Besitzer

Ein zuverlässiger Polling-Controller speichert seinen Datensatz dauerhaft und stellt sicher, dass immer nur ein Worker einen Job besitzt. Ohne diese beiden Eigenschaften erzeugen Neustarts und parallele Agenten doppelte Prüfungen oder widersprüchliche Folgeaktionen.

Der Besitzer kann ein Prozess-Lease, eine Datenbanksperre oder ein anderes dauerhaftes Verfahren sein, das zu Ihrer Umgebung passt. Das Verfahren muss ablaufen, wenn der Worker stirbt, und ein neuer Besitzer muss den vollständigen Datensatz laden, bevor er irgendetwas sendet. Ein einfaches Boolean im Arbeitsspeicher ist keine Besitzregel, sobald ein zweiter Agentenprozess existiert.

Speichern Sie nach jedem wichtigen Ereignis: Jobübermittlung, Planung der nächsten Prüfung, gesendete Statusanfrage, empfangene Antwort, Zustandswechsel und Eskalation. Sie brauchen kein eigenes Journal für jedes Debug-Detail, müssen aber die Fakten wiederherstellen können, die Berechtigungen und Budgets beeinflussen.

Dieser Pseudocode zeigt die Reihenfolge, die die meisten versehentlichen Schleifen verhindert:

load operation
if operation is terminal or escalated:
    exit
if current_time \u003e= operation.deadline_at:
    record timeout and escalate
    exit
if operation.status_requests_used \u003e= operation.max_status_requests:
    record budget exhaustion and escalate
    exit
if current_time \u003c operation.next_poll_at:
    schedule wakeup and exit

acquire ownership lease
reload operation
increment status_requests_used and persist
send one status request
persist response metadata

if response has terminal success and required result fields are valid:
    record success
else if response has terminal failure or unknown state:
    record stop reason and escalate
else if response requires waiting:
    calculate next_poll_at with provider guidance, backoff, and jitter
    persist next_poll_at
else:
    record integration failure and escalate

Das erneute Laden nach dem Erwerb des Besitzes ist Absicht. Ein anderer Worker kann den Job beendet haben, während dieser Worker auf das Lease wartete. Überspringen Sie diesen Schritt, sehen Sie später womöglich zwei Agenten, die dasselbe Ergebnis abrufen oder veröffentlichen.

Halten Sie ein Lease nicht während des Schlafens. Halten Sie es nur, während Sie den Datensatz aktualisieren und die eine Anfrage senden, sofern Ihr Besitzmodell dies sicher erlaubt. Ein Lease, das für die gesamte Dauer eines langsamen externen Jobs gehalten wird, wird zum Problem, wenn ein Laptop einschläft oder ein Prozess beendet wird.

Ein Statusendpunkt sollte aus Sicht des Agenten schreibgeschützt bleiben. Führen Sie das Abrufen von Ergebnissen, das Stornieren und die Veröffentlichung in nachgelagerten Systemen als getrennte Aktionen mit eigenen Datensätzen. Wenn Sie alles in einer Polling-Funktion zusammenfassen, wird aus einem harmlosen Timer eine verborgene Workflow-Engine.

Menschliche Freigabe gehört an die Eskalationsgrenze

Die meisten routinemäßigen Prüfungen brauchen keinen Klick eines Menschen, solange sie innerhalb des ursprünglich freigegebenen Vorgangs, des Berechtigungsumfangs, der Frist und des Anfragebudgets bleiben. Eine Freigabe für jeden Lesezugriff führt dazu, dass Menschen zustimmen, ohne zu lesen, und verlangsamt die Arbeit ohne Sicherheitsgewinn.

Eine Freigabe ist sinnvoll, wenn der Agent eine neue Berechtigungsgrenze anfordert: mehr Zeit als die ursprüngliche Frist, ein höheres Anfragebudget, einen Stornierungsaufruf, eine erneute Übermittlung, andere Zugangsdaten oder die Verwendung eines nicht validierten Ergebnisses. Das sind Änderungen am Vorgang und keine gewöhnlichen Beobachtungen.

Sallyport kann die API-Zugangsdaten von einem MCP-fähigen Agenten fernhalten, während die Anwendung den Statusaufruf ausführt und das Ergebnis zurückgibt. Die Einstellung für einzelne Aufrufe passt zu Vorgängen, bei denen jede Verwendung bestimmter Zugangsdaten, auch ein Statusaufruf, eine ausdrückliche Freigabe braucht. Sie kann aber kein ungebundenes Polling reparieren.

Wählen Sie das Freigabemodell nach den Folgen. Ein risikoarmer Statusaufruf beim Provider kann innerhalb einer sitzungsbasierten Autorisierung bleiben. Eine privilegierte Status-API, die vertrauliche Jobmetadaten offenlegt, braucht möglicherweise eine Freigabe pro Aufruf oder engere Zugangsdaten. In beiden Fällen müssen Sie die Grenzen des Controllers festlegen, bevor Sie entscheiden, wie eine Anfrage autorisiert wird.

Lassen Sie nicht eine Eingabe entscheiden, ob eine Verlängerung der Frist harmlos ist. Die Anfrage sollte den aktuellen Zustand, die verstrichene Zeit, die bisherigen Aufrufe, das vorgeschlagene zusätzliche Budget und die erwarteten Folgen einer Fortsetzung nennen. So kann eine prüfende Person eine Verlängerung ablehnen, die ein Veröffentlichungsfenster verpasst oder veraltete Daten erzeugt.

Protokollieren Sie die Entscheidung zu warten, nicht nur die Anfrage

Ein Anfrage-Log zeigt, dass ein Agent /jobs/exp_71c aufgerufen hat. Es zeigt nicht, ob der Aufruf durch den Polling-Plan erlaubt war, ob der Agent Retry-After ignorierte oder ob der Job seine Frist bereits überschritten hatte.

Protokollieren Sie mit jedem Aufruf die Entscheidung des Controllers: aktueller Zustand, nächste geplante Zeit, Quelle der Verzögerung, Anfragezähler, Frist, Antwortcode, geparster Jobzustand und daraus folgende Entscheidung. Die Quelle der Verzögerung kann provider_retry_after, provider_poll_hint, local_backoff oder manual_extension sein. Dieses kleine Feld erspart nach einem Vorfall viele Diskussionen.

Eine hilfreiche Prüfsequenz liest sich wie eine Geschichte:

10:20:00 submitted job exp_71c, deadline 11:00:00, budget 12
10:20:05 polled, state queued, next poll 10:20:14 from local backoff
10:20:14 polled, state running, next poll 10:20:31 from local backoff
10:20:31 received 503, Retry-After 120, next poll 10:22:31 from provider guidance
10:22:31 polled, state running, next poll 10:23:48 from local backoff
10:58:00 polled, state running, request budget exhausted, escalated

Dieser Datensatz macht einen schlechten Controller sofort sichtbar. Zeigen die Zeitstempel trotz einer Verzögerung des Providers eine Anfrage pro Sekunde, haben Sie einen Beleg. Behauptet ein Agent, ein Job sei abgelaufen, obwohl sein letzter Zustand succeeded war, gibt es eine konkrete Stelle zur Korrektur.

Sallyport erfasst Agentensitzungen und einzelne Aufrufe in einem verschlüsselten, hashverketteten Audit-Log, und sp audit verify kann diese Kette offline über dem Chiffretext prüfen. Solche Nachweise sind besonders nützlich, wenn Ihr eigener Vorgangsdatensatz erklärt, warum jeder beobachtete Aufruf stattgefunden hat.

Messen Sie die Qualität des Pollings nicht daran, ob Jobs irgendwann fertig werden. Messen Sie, ob jeder Job ein terminales Ergebnis oder eine begrenzte Eskalation erreicht, ob Agenten die Warteanweisungen des Providers beachten und ob eine zuständige Person eine strittige Entscheidung nachvollziehen kann. Die erste Änderung, die ich an einer unkontrollierten Schleife vornehmen würde, ist einfach: Speichern Sie Frist und Anfragebudget, bevor der Agent seine erste Statusanfrage sendet.