Aufrufe von KI-APIs abbrechen: Verwaiste Arbeit stoppen und Ressourcen freigeben

Eine geschlossene Ansicht bedeutet nicht, dass ein Vorgang beendet ist

Wenn eine Generierung abgebrochen wird, erwartet der Nutzer meist, dass die Arbeit aufhört. Die sichtbare Aktion – etwa ein Klick auf eine Schaltfläche, der Wechsel zu einer anderen Ansicht oder das Ende der Wartezeit – beschreibt jedoch nur, was in der Benutzeroberfläche passiert ist. Sie beweist nicht, was mit der HTTP-Anfrage, dem Serverprozess oder einer möglichen Verarbeitung durch einen externen Anbieter geschehen ist. Das sind unterschiedliche Schichten, und jede kann ihren eigenen Lebenszyklus haben.

Deshalb sollte eine Integration an jeder Grenze genau festlegen, was „Abbrechen“ bedeutet. Der Browser kann aufhören, auf eine Antwort zu warten; der Server kann eine von ihm gesteuerte Aufgabe beenden; und eine entfernte API bietet möglicherweise einen dokumentierten Mechanismus zum Abbrechen eines angenommenen Vorgangs – oder auch nicht. Wenn eine Schicht das Signal nicht weitergibt oder den zu stoppenden Vorgang nicht kennt, kann die Arbeit dort weiterlaufen, obwohl der Nutzer das Ergebnis nicht mehr sieht.

Das hat praktische Konsequenzen: Stelle einen Abbruch nicht als gültige Antwort dar, und behaupte nicht, der Anbieter habe die Verarbeitung beendet, solange du das nicht überprüft hast. Die Anwendung kann bestätigen, dass sie eine Abbruchanforderung erhalten hat und lokal nicht mehr wartet. Für weitergehende Aussagen brauchst du Belege zum Verhalten der konkreten Integration, darunter die Dokumentation des Anbieters und, wenn möglich, ein beobachtbares Testergebnis.

Lege fest, was abgebrochen wird, bevor du Code schreibst

Ein Abbruchsignal braucht einen klar definierten Geltungsbereich. Es kann das Warten der Benutzeroberfläche, eine HTTP-Verbindung, eine Backend-Aufgabe oder einen identifizierbaren Vorgang im entfernten Dienst betreffen. In einem einfachen System hast du vielleicht nur Kontrolle über die ersten beiden Ebenen. Bei einer Architektur mit einem zwischengeschalteten Server beendet der Abbruch im Browser nicht automatisch die Arbeit dieses Servers: Die Anwendung muss die Verbindungsunterbrechung erkennen oder ein ausdrückliches Signal empfangen und es in eine Aktion für die entsprechende Aufgabe umsetzen.

Auch den Grund für den Abbruch solltest du unterscheiden. Ein ausdrücklicher Abbruch liegt vor, wenn der Nutzer die Arbeit beenden möchte. Das Verlassen einer Ansicht kann dagegen durch Navigation oder einen Verbindungsabbruch geschehen, ohne dass eine bewusste Abbruchabsicht dahintersteht. Ein Timeout tritt ein, wenn eine konfigurierte Frist abläuft. In allen drei Fällen wartet die Anwendung möglicherweise nicht mehr – doch die Ereignisse bedeuten nicht dasselbe, sollten nicht zwingend gleich dargestellt werden und sagen nicht unbedingt aus, ob die entfernte Arbeit beendet wurde.

Definiere Endzustände, die beschreiben, was die Anwendung überprüft hat, nicht was sie vermutet. Mögliche Zustände sind beispielsweise: abgeschlossen, Abbruch angefordert, lokales Zeitlimit überschritten und Verbindungsabbruch erkannt. Wenn das System einen entfernten Abbruch über einen dokumentierten Mechanismus bestätigen kann, lässt sich dieses Ergebnis gesondert erfassen. Eine klare Trennung der Zustände verbessert sowohl die Benutzeroberfläche als auch die spätere Diagnose.

Gib das Signal über die Grenzen weiter, die du kontrollierst

Im Browser kannst du mit AbortController ein Signal erstellen und es einer mit fetch ausgeführten Anfrage zuordnen. Wird das Signal abgebrochen, kann der Client das Warten auf diese Anfrage unterbrechen. Damit ist ein Teil des Problems gelöst: Der Code der Benutzeroberfläche behandelt die Antwort nicht länger als einen noch wartenden Vorgang. Das beweist jedoch nicht, dass eine über die Verbindung hinaus gestartete Aufgabe beendet wurde.

Die nächste Grenze ist meist das Backend. Wenn der Browser mit einem eigenen Dienst kommuniziert, braucht dieser Dienst eine Regel, um die eingehende Anfrage mit der gestarteten Arbeit zu verknüpfen. Abhängig von Plattform und verwendeter Bibliothek kann er ein Abbruchsignal, eine Verbindungsunterbrechung oder beides erkennen. Prüfe, welche Fähigkeiten dein Server und dein HTTP-Client tatsächlich haben. Gehe nicht davon aus, dass eine Abstraktion den Abbruch weitergibt, nur weil die Benutzeroberfläche eine Abbrechen-Schaltfläche hat.

Wenn das Backend eine externe API aufruft, muss geprüft werden, ob der verwendete HTTP-Client ein Abbruchsignal unterstützt und was beim Einsatz dieses Signals geschieht. Anschließend ist die Dokumentation der konkreten API zu prüfen: Bietet sie einen Mechanismus zum Abbrechen eines bereits angenommenen Vorgangs, oder lässt sich lediglich die lokale Verbindung unterbrechen? Das sind unterschiedliche Fähigkeiten. Einige APIs bieten für bestimmte Vorgänge eine ausdrückliche Abbruchoperation. Daraus lässt sich jedoch nichts Allgemeingültiges über KI-Generierungsdienste ableiten.

Auch Leitlinien für asynchrone API-Entwürfe sprechen dafür, laufende Vorgänge abbrechbar zu machen. Das ist ein Designprinzip, aber keine Garantie dafür, dass jede Abhängigkeit oder jeder Anbieter diese Fähigkeit umsetzt. Es ist auch keine Anleitung, wie ein Abbruch zwischen Systemen weitergegeben wird. Dokumentiere für jede Schicht, wer das Signal empfängt, welche Aktion möglich ist und welches Ergebnis sich beobachten lässt.

Beispiel mit AbortController im Browser

Das folgende Beispiel sendet eine Anfrage an eine eigene Backend-Route und ermöglicht es, das Warten des Browsers abzubrechen. Dabei wird angenommen, dass die Route ein Objekt mit dem Feld prompt entgegennimmt und bei erfolgreichem Abschluss JSON mit einem Feld text zurückgibt. Die Route dient nur der Veranschaulichung: Das Backend muss den Vertrag implementieren und gesondert festlegen, wie es die Anfrage behandelt, den Abbruch weitergibt und welche Aussagen zur externen API bestätigt werden können.

Die Funktion prüft, ob das übergebene Signal bereits vor dem Start der Anfrage abgebrochen wurde. Außerdem verhindert sie eine Aktualisierung der Benutzeroberfläche, wenn der Abbruch zuerst registriert wird. In einer echten Benutzeroberfläche verbindest du die Funktion mit der passenden Abbrechen-Schaltfläche und deaktivierst diese, sobald der Vorgang einen Endzustand erreicht. Das Beispiel beweist nicht, dass das Backend oder der Anbieter die Verarbeitung beendet hat.

async function generate(prompt, output, signal) {
  if (signal.aborted) {
    output.textContent = "Abbruch vor dem Senden angefordert.";
    return;
  }

  output.textContent = "Generierung läuft …";

  try {
    const response = await fetch("/api/generate", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ prompt }),
      signal
    });

    if (!response.ok) throw new Error(`HTTP ${response.status}`);
    const result = await response.json();

    if (!signal.aborted) output.textContent = result.text;
  } catch (error) {
    if (signal.aborted || error.name === "AbortError") {
      output.textContent = "Es wird nicht mehr auf die Antwort gewartet.";
      return;
    }
    output.textContent = "Die Anfrage konnte nicht abgeschlossen werden.";
  }
}

const controller = new AbortController();
const task = generate("Fasse das Dokument zusammen", document.querySelector("#output"), controller.signal);
// Rufe controller.abort() über die Abbrechen-Aktion auf.
// Behalte task, wenn du auf das Ende des lokalen Codes warten musst.

Behandle ein Timeout als Frist, nicht als Beweis für einen Abbruch

Ein Timeout legt fest, wie lange eine Schicht zu warten bereit ist. In der Benutzeroberfläche kann es eine Frist geben, eine weitere auf dem Server und eine zusätzliche im HTTP-Client, der die Verbindung zum Anbieter herstellt. Diese Fristen müssen bewusst aufeinander abgestimmt werden. Wenn eine Schicht aufgibt, bevor sie eine andere informiert, kann der Vorgang weiterhin Ressourcen in einer Schicht beanspruchen, die ihn noch als aktiv betrachtet.

Wenn eine Frist abläuft, protokolliere, welche Uhr und auf welcher Schicht abgelaufen ist. „Browser-Timeout“ ist genauer als „das Modell hat sein Zeitlimit überschritten“ – es sei denn, es gibt Belege dafür, dass der entfernte Dienst genau dieses Ergebnis gemeldet hat. Die Anwendung kann aufhören zu warten, bei den verfügbaren Schichten eine Unterbrechung anfordern und den Zustand „Frist abgelaufen“ anzeigen. Sie sollte daraus keine bestätigte Abbruchmeldung machen.

Die Auswirkungen auf Nutzung oder Abrechnung hängen von der API und ihren Bedingungen ab. Die Dokumentation einer konkreten API kann beschreiben, was ihre Abbruchoperation bewirkt. Daraus lässt sich nicht das Verhalten eines anderen Endpunkts oder Anbieters ableiten. Wenn diese Auswirkungen relevant sind, suche die spezifische offizielle Dokumentation, prüfe, welche Arbeitseinheit abgebrochen wird, und validiere das Ergebnis mit einem kontrollierten Test. Wenn die Dokumentation keine klare Antwort gibt, sollte diese Unsicherheit im Produkt und in der Kostenrichtlinie erhalten bleiben.

Vermeide widersprüchliche Zustände bei konkurrierenden Ereignissen

Antwort und Abbruch können nahezu gleichzeitig eintreffen. Verarbeitet die Benutzeroberfläche beide Ereignisse ohne gemeinsame Regel, könnte sie zunächst „abgebrochen“ anzeigen und den Zustand anschließend mit einer verspäteten Antwort überschreiben. Umgekehrt könnte sie eine Antwort darstellen, obwohl der Nutzer bereits um einen Abbruch gebeten hatte. Die Lösung besteht nicht darin, zu erraten, welches Ereignis im entfernten System zuerst eingetreten ist. Entscheidend ist eine Festlegung dazu, welcher terminale Zustand in der Anwendung Vorrang hat.

Eine einfache Regel für die Benutzeroberfläche lautet: Sobald für einen Vorgang der erste terminale Übergang registriert wurde, dürfen spätere Aktualisierungen für denselben Vorgang den Zustand nicht mehr ändern. Alternativ kannst du jeder Anfrage eine Kennung zuweisen und Antworten verwerfen, die zu einem Vorgang gehören, der nicht mehr aktiv ist. Welche Regel passt, hängt vom Produkt ab. Falls eine abgeschlossene Antwort trotz eines spät ausgelösten Abbruchs erhalten bleiben darf, muss auch diese Richtlinie ausdrücklich festgelegt werden.

Vermische die Darstellung nicht mit dem operativen Sachverhalt. Die Benutzeroberfläche kann einen Vorgang lokal als abgebrochen kennzeichnen, während das Backend protokolliert, dass sich der entfernte Abbruch nicht bestätigen ließ. Wenn es relevant ist, solltest du diese Angaben in internen Zuständen oder Protokollen getrennt halten. So wirkt eine verspätete Antwort nicht wie ein Beweis dafür, dass der Abbruch rückgängig gemacht wurde, und das Schließen einer Verbindung nicht wie der Abschluss der Arbeit.

Teste jede Phase und jede Grenze

Ein Test, der erst nach dem Eintreffen einer Antwort auf „Abbrechen“ klickt, prüft keinen Abbruch während der laufenden Arbeit. Entwickle eigene Testfälle für die relevanten Zeitpunkte und beobachte sowohl die Benutzeroberfläche als auch das Backend. Bei einer externen API solltest du nur prüfen, was sich anhand der Integration und ihrer Dokumentation tatsächlich beobachten lässt. Das Verschwinden eines Ergebnisses auf dem Bildschirm ist kein Hinweis darauf, dass der Anbieter die Verarbeitung beendet hat.

Nimm einen Testfall für einen Abbruch vor dem Senden auf: Ist das Signal beim Aufruf der Funktion bereits abgebrochen, sollte die Anfrage nicht gestartet werden. Teste außerdem den Abbruch nach dem Start der Anfrage, aber vor dem Eintreffen einer Antwort, und während einer laufenden Antwort, sofern der Endpunkt einen solchen Zeitraum beobachten lässt. Prüfe das Schließen oder Verlassen der Ansicht entsprechend der vom Produkt festgelegten Richtlinie.

Führe schließlich ein Rennen zwischen Antwort und Abbruch herbei und prüfe, ob der terminale Zustand deterministisch ist. Bei einem Timeout muss als Ablauf der Frist protokolliert werden – nicht als ausdrückliche Aktion des Nutzers. Prüfe in jedem Test, ob lokale Aufgaben und Verbindungen offen bleiben und ob das Backend weiterhin aktive Arbeit hat. Lässt sich entfernte Aktivität nicht untersuchen, dokumentiere das als Einschränkung, statt zu behaupten, sie sei beendet.

Prüfe Ressourcen und Folgen vor der Bereitstellung

Die Prüfung sollte die gesamte Kette umfassen, nicht nur den Code der Abbrechen-Schaltfläche. Bestätige, dass der lokale HTTP-Client ein Abbruchsignal entgegennehmen kann, dass das Backend dieses Signal der richtigen Aufgabe zuordnet und dass ein entfernter Mechanismus – sofern vorhanden – zum verwendeten Endpunkt und Vorgangstyp passt. Die Abbruchfunktionen eines bestimmten Produkts beweisen nicht, dass eine andere API desselben Anbieters oder ein anderer Anbieter dasselbe Verhalten zeigt.

Achte auch auf die lokale Bereinigung: Zugehörige Hilfsaufgaben, Listener, Verbindungen und Referenzen sollten nicht ohne bekannten Grund aktiv bleiben. Stelle bei Diensten mit mehreren gleichzeitigen Anfragen sicher, dass ein Signal nur den zugehörigen Vorgang abbricht und nicht eine Aufgabe, die andere Nutzer gemeinsam verwenden. Protokolliere Vorgangskennungen und Endzustände so, dass sich nachvollziehen lässt, was angefordert und was bestätigt wurde.

Bevor du Aussagen zu Kosten, Nutzung oder entfernter Verarbeitung machst, prüfe die offizielle Dokumentation der konkreten Integration und führe begrenzte Tests durch, die mit deren Bedingungen vereinbar sind. Eine API für Anrufe im Stapelbetrieb dokumentiert beispielsweise eine Abbruchoperation für ihre Anrufe und Empfänger. Das ist ein Beleg für genau diesen Endpunkt, nicht für Textgenerierung. Bewahre diese Unterscheidung im Design, in den Tests und in der Kommunikation mit Nutzern.

Abschließender Maßstab: Berichte, was du weißt, und prüfe, was offen ist

Das grundlegende Muster ist einfach, auch wenn seine Umsetzung von der Architektur abhängt: Erfasse den Grund, gib das Signal durch die Schichten weiter, die du kontrollierst, wende eine deterministische Zustandsregel an und prüfe, welche Ressourcen noch aktiv sind. AbortController kann im Browser dabei helfen, das Warten zu unterbrechen. Es ersetzt weder den Abbruch im Backend noch einen entfernten Mechanismus, den eine API möglicherweise bereitstellt.

Beantworte vor der Integration eines Dienstes schriftlich folgende Fragen: Unterstützt die HTTP-Bibliothek Abbrüche? Erkennt das Backend, wenn die Ansicht verlassen wird? Verfügt die externe API über eine dokumentierte Operation zum Stoppen einer bereits angenommenen Aufgabe? Was lässt sich nach ihrem Einsatz beobachten? Was ist über Nutzung und Abrechnung bekannt? Fehlt eine Antwort, halte die Unsicherheit fest und verspreche nicht mehr, als die Integration nachweislich leistet.

Ein korrekter Abbruch bedeutet nicht, garantieren zu können, dass die Arbeit in jeder Schicht verschwindet. Er bedeutet, klare Zustände zu führen, unterbrechbare Arbeit in der eigenen Anwendung zu beenden, lokale Ressourcen freizugeben, Rennen zu testen und den Geltungsbereich jeder Aktion ehrlich zu kommunizieren.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.