Skip to main content
idempotencyKey ist ein optionaler, vom Aufrufer gelieferter String, der eine Einreichung deduplizierend macht. Senden Sie denselben Schlüssel zweimal, wird die zweite Einreichung dem Task zugeordnet, den die erste erstellt hat, statt neue Arbeit einzureihen.
Ohne ihn gibt es keine Deduplizierung: Jede Einreichung erzeugt einen neuen Task. Für einmalige Abfragen ist das eine legitime Wahl, für alles, was ein Cronjob oder ein wiederholender Worker doppelt einreichen könnte, die falsche.
Ein guter Schlüssel ergibt sich deterministisch aus der Arbeit selbst, nicht aus dem Versuch. Setzen Sie ihn aus den Kennungen der Arbeitseinheit zusammen, etwa "{jobId}:{promptId}:{engine}", dann erzeugt eine Wiederholung ganz natürlich denselben Schlüssel.

​
Einzel und Batch unterscheiden sich bewusst

Das ist die einzige Stelle, an der sich die beiden Endpunkte unterscheiden, und sie führt oft zu Fehlern.
Der Einzel-Endpunkt behält die Semantik der expliziten Erstellung: Sie wollten einen Task erstellen, der Task existiert bereits, das ist ein Konflikt, und Sie sollten davon erfahren. Der Batch-Endpunkt wertet Duplikate als Erfolg. Sein Aufrufer ist typischerweise ein Worker, der nach einem Neustart einen ganzen Job erneut einreicht. Einen Batch mit 500 Einträgen als fehlgeschlagen zu werten, weil ein Schlüssel bereits in der Warteschlange war, würde den Sinn von Idempotenzschlüsseln zunichtemachen. Das zurückgegebene results[i].task ist der bestehende Task, sodass Ihre Task-Zuordnung weiter aufgeht.

​
Ergebnisse den Einreichungen zuordnen

Es gibt zwei unabhängige Anker, und Sie brauchen beide:
​
integer
Entspricht positionsgenau 1:1 Ihrem Eingabe-Array. Damit ordnen Sie die Batch-Antwort den gesendeten Tasks zu.
​
string
Wird unverändert zurückgegeben. Damit ordnen Sie den Webhook zu, der Minuten später, ungeordnet und ohne Bezug auf Ihr ursprüngliches Array eintrifft.
Wenn Sie keinen idempotencyKey angegeben haben, wird das Feld im Task-Objekt weggelassen statt als null zurückgegeben. Intern nutzt der Task seine eigene uuid als Schlüssel, die per Konstruktion eindeutig ist und daher nie dedupliziert.

​
Lebensdauer von Schlüsseln

Schlüssel dauerhaft aufbewahrter Tasks bleiben nach Abschluss, Fehlschlag und dem 24-stündigen öffentlichen Polling-Fenster reserviert. Ein 404 beim Polling gibt den Schlüssel nicht frei. Verwenden Sie für Übertragungswiederholungen einer Einreichung denselben Schlüssel und für einen separaten Lauf einen neuen Ausführungsschlüssel (zum Beispiel mit dem Suffix :r1). Ein UUID-Format ist nicht erforderlich. Datensätze, die vor Aktivierung der dauerhaften Aufbewahrung bereits in die Altdaten verschoben wurden, reservieren nachträglich keine Schlüssel.