Warum dein Bot denselben Auftrag zweimal ausführt

Ein Ablauf sendet den Auftrag „Aufgabe anlegen“ an ein anderes System. Dort entsteht die Aufgabe. Auf dem Rückweg geht die Bestätigung verloren oder kommt zu spät an. Der sendende Ablauf sieht nur: keine rechtzeitige Antwort. Also versucht er es erneut.

Das ist ein schematisches Beispiel. Wie ein konkretes Werkzeug wiederholt, musst du in dessen Dokumentation und Einstellungen prüfen. Der grundsätzliche Fall ist leicht zu übersehen: Der Absender kennt seinen eigenen Zeitablauf, aber nicht immer den Zustand beim Empfänger.

Derselbe Vorgang braucht dieselbe Kennung

Vergib für einen logischen Auftrag eine Kennung, die bei seinen Wiederholungen erhalten bleibt. Nicht jeder neue Versuch bekommt eine neue Auftragsnummer. Sonst sieht der Empfänger zwei verschiedene Vorgänge und kann sie nicht als Wiederholung erkennen.

Bei einer Aufgabe aus einer E-Mail könnte die Kennung aus einer dauerhaft gespeicherten internen Eingangs-ID und der Art der Aktion entstehen. Ob eine vorhandene Nachrichten-ID ausreichend ist, hängt vom Postsystem und seiner Verarbeitung ab. Im E-Mail-zu-Aufgabe-Ablauf wird deshalb ein eigener Eingang gespeichert, bevor die Aktion beginnt.

Eine Operation heißt idempotent, wenn ihre Wiederholung im betrachteten System zum selben vorgesehenen Ergebnis führt wie die einmalige Ausführung. Zweimal „Status auf erledigt setzen“ kann diese Eigenschaft haben. Zweimal „neue Aufgabe hinzufügen“ hat sie ohne weitere Absicherung nicht.

Ein Häkchen nachher kann zu spät sein

Der einfache Plan lautet: Vor dem Anlegen nachsehen, ob die Kennung schon erledigt ist. Danach erledigt markieren. Bei zwei gleichzeitig laufenden Versuchen können aber beide „noch offen“ lesen und beide die Aktion ausführen.

Je nach System braucht die Kennung daher eine tatsächlich eindeutige Speicherung, eine atomare Reservierung oder eine vom Ziel unterstützte Idempotenzfunktion. „Atomar“ bedeutet hier, dass der entscheidende Zustandswechsel nicht zwischen zwei konkurrierenden Zugriffen auseinanderfällt. Ein grüner Status in der Oberfläche beweist das nicht. Im Betriebsmodell-Vergleich ist die Behandlung solcher Zustände deshalb ein Prüfpunkt.

Auch eine Reservierung reicht nicht für eine allgemeine Genau-einmal-Garantie. Wenn das Ziel gearbeitet hat und die lokale Bestätigung fehlt, bleibt der Ausgang unklar. Speichere nach Möglichkeit die Ziel-ID und gleiche den Vorgang dort ab. Lässt das Ziel weder idempotente Schlüssel noch eine verlässliche Abfrage zu, muss dieser Fehlerfall zur manuellen Prüfung gehen.

Antworten und Aktionen getrennt betrachten

Eine Wiederholung darf manchmal einen neuen Entwurf erzeugen. Sie darf nicht unbemerkt zweimal denselben Auftrag versenden. Sprachmodelle bringen zusätzlich die Frage mit, ob der neue Entwurf denselben Inhalt hat. Warum ein überzeugender Chatbot-Text prüfbedürftig bleibt, ist ein anderes Problem als die doppelte Zustellung.

Ein FAQ-Bot mit freigegebenen Fundstellen kann beim zweiten Aufruf erneut antworten. Sobald ein Button eine verbindliche Übergabe anlegt, gehört diese Aktion in ein eigenes, abgesichertes Verfahren. Der Textteil darf nicht stillschweigend die Freigabe ersetzen.

Bei Trading-Bots und ihren Backtests wird die Trennung besonders anschaulich: Ein berechnetes Signal ist noch keine bestätigte Order. Eine Wiederholung im Modell und eine erneute reale Ausführung können verschiedene Folgen haben. Unsere Beispiele zeigen technische Abläufe, keine Anleitung zum Handel.

Den schwierigen Fall absichtlich auslösen

Teste einen doppelten Eingang, zwei gleichzeitige Versuche, eine verspätete Antwort und einen Abbruch nach erfolgreicher Zielaktion. Prüfe danach das Zielsystem, nicht nur die Erfolgsmeldung im Ablauf. Ein sauberer Test benennt auch, welche Fälle noch nicht automatisch aufgelöst werden können.

Begrenze währenddessen die Rechte. Ein Testkonto braucht keine allgemeine Lösch- oder Zahlungsberechtigung. Unser Leitfaden für kleine Bot-Vollmachten hilft, aus einem Testfehler keinen großen Vorfall zu machen.

Für einen kleinen Ablauf kann eine gut gepflegte manuelle Klärliste sinnvoller sein als eine komplizierte Eigenentwicklung. Dort stehen Eingang, Kennung, letzter bekannter Zustand und die Person, die nachsehen soll. Eine Wiederholung ist ein normaler Betriebsfall. Sie sollte nicht jedes Mal ein Rätsel erzeugen.