40 Sekunden, dann zieht Make den Stecker: das Timeout-Problem, das keiner einplant
Ein langsamer API-Aufruf, ein hartes Zeitlimit, und die Rechnung steht zweimal im System. Warum Timeouts Doppelbuchungen verursachen und wie Sie das verhindern.
Ein Kunde bekam von einem Lieferanten eine wütende Mail: zwei identische Rechnungen, gleicher Betrag, dazwischen eine Lücke im Nummernkreis. Die Buchhaltung schwor, sie hätten die Rechnung nur einmal angelegt. Hatten sie auch. Die Automatisierung hatte sie zweimal angelegt.
Was war passiert: Das Make-Szenario legte die Rechnung im Buchhaltungssystem an, und das dauerte an dem Tag ungewöhnlich lange, weil deren API träge war. Nach 40 Sekunden zog Make den Stecker, das ist das harte Szenario-Zeitlimit in den unteren Plänen. Die Rechnung war zu dem Zeitpunkt längst angelegt, aber Make hatte die Erfolgsmeldung nie bekommen. Also galt der Lauf als fehlgeschlagen und wurde wiederholt. Zweite Rechnung.
Zwei Arten, wie Timeouts Sie treffen
Es gibt zwei Sorten Timeout, und die meisten Leute denken nur an die erste.
Die erste ist der Aufruf, der ewig hängt. Ihr Workflow ruft eine fremde API auf und wartet. Und wartet. Wenn Sie kein Zeitlimit gesetzt haben, wartet er im Zweifel, bis die Plattform selbst irgendwann eingreift. In der Zwischenzeit ist dieser Lauf blockiert, und je nach Aufbau stauen sich die nächsten dahinter.
Die zweite ist die gefährlichere: das harte Zeitlimit der Plattform. Make beendet ein Szenario nach 40 Sekunden, in höheren Plänen etwas später. Eine Zapier-Task, eine AWS-Lambda-Funktion, jede Serverless-Umgebung hat so eine Obergrenze. Wird sie überschritten, wird Ihr Workflow mittendrin abgeschnitten. Nicht sauber beendet. Abgeschnitten.
Kurz zur Frage, die dann kommt: Was passiert mit den Daten, wenn ein Workflow mitten im Lauf abbricht? Das hängt davon ab, wie weit er war. Alles vor dem Abbruch ist passiert, alles danach nicht. Wenn Schritt drei einen Datensatz angelegt und Schritt fünf ihn als erledigt markiert hätte, dann existiert der Datensatz jetzt, ist aber nirgends als erledigt vermerkt. Genau da entstehen Doppelbuchungen, halbe Bestellungen und Kunden, die zweimal die Willkommensmail bekommen.
Warum das im Test nie passiert
Beim Bauen ist alles schnell. Die Test-API antwortet in 200 Millisekunden, das Szenario ist in zwei Sekunden durch, von 40 Sekunden ist man meilenweit entfernt. Der Timeout ist eine theoretische Zahl, um die sich niemand kümmert.
Im Betrieb ist die Welt langsamer. Die fremde API hat einen schlechten Tag. Ein Anhang ist zehnmal so groß wie im Test. Es kommen 500 Datensätze statt fünf. Und plötzlich kratzt ein Lauf, der sonst zwei Sekunden brauchte, an der 40-Sekunden-Grenze. Der Fehler wartet geduldig auf den ungünstigsten Moment.
Woran Sie merken, dass ein Timeout dahintersteckt
Timeouts sehen im Nachhinein oft aus wie andere Fehler, deshalb ein paar Signale. Zeigen Ihre Protokolle Meldungen wie operation timed out, gateway timeout oder einen Status 504, ist der Fall klar. Häufiger ist es aber unauffälliger: Ein Lauf steht in der Historie auf fehlgeschlagen, obwohl im Zielsystem der Datensatz sauber angelegt wurde. Genau diese Kombination, Fehler hier, korrektes Ergebnis dort, ist das Markenzeichen eines Timeouts nach erfolgreicher Aktion.
Ein zweites Signal ist die Uhrzeit. Wenn Läufe immer dann scheitern, wenn viel los ist, morgens beim Import oder am Monatsende beim Abrechnungslauf, dann ist die Datenmenge der Auslöser und die Plattformgrenze der eigentliche Gegner. Ein Fehler, der nur unter Last auftritt, ist fast immer eine Frage von Zeit oder Menge.
Was tatsächlich hilft
Setzen Sie Timeouts bewusst, statt sie dem Zufall zu überlassen. Zu einem HTTP-Aufruf gehört ein explizites Zeitlimit, fünf oder zehn Sekunden sind für die meisten APIs großzügig. Ein Aufruf, der nach zehn Sekunden nicht antwortet, antwortet meistens auch nach sechzig nicht. Lieber sauber abbrechen und kontrolliert wiederholen, als blind warten.
Zerlegen Sie lange Läufe. Wenn ein Szenario nah an die Plattformgrenze kommt, verarbeiten Sie nicht 500 Datensätze in einem Durchlauf, sondern 50 pro Lauf in zehn Läufen. Kürzere Läufe treffen das Zeitlimit seltener und sind, wenn doch etwas schiefgeht, leichter zu reparieren.
Beobachten Sie außerdem, wie lange Ihre Läufe dauern, nicht nur ob sie durchlaufen. Ein Szenario, das über Wochen von zwei auf zwanzig Sekunden klettert, reißt die 40-Sekunden-Grenze irgendwann, und zwar ohne Vorwarnung. Wer die Laufzeit im Blick hat, sieht das Problem kommen, statt es am Anruf eines verärgerten Kunden zu merken.
Und der wichtigste Punkt, der Doppelbuchungen verhindert: Machen Sie den Schritt, der etwas Bleibendes erzeugt, wiederholbar. Bevor der Workflow eine Rechnung anlegt, soll er prüfen, ob sie schon existiert. In der Praxis heißt das eine eindeutige Kennung pro Vorgang, etwa die Bestellnummer, die das Zielsystem ablehnt, wenn sie schon da ist. Dann darf der Lauf ruhig zehnmal wiederholt werden, ohne dass zehn Rechnungen entstehen. Wer tiefer einsteigen will: Das ist das Prinzip der Idempotenz, über das wir hier schon ausführlicher geschrieben haben.
Was ich daraus mitgenommen habe
Ein Timeout ist keine Fehlfunktion, sondern eine Entscheidung, die die Plattform für Sie trifft, wenn Sie sie nicht selbst treffen. Und sie trifft sie im schlechtesten Moment: nicht bevor etwas passiert, sondern mittendrin.
Wenn Sie einen Workflow haben, der etwas anlegt, bucht oder verschickt, stellen Sie sich eine Frage: Was passiert, wenn er genau nach diesem Schritt abbricht? Können Sie die Antwort nicht ruhigen Gewissens geben, wissen Sie, wo Ihr nächstes Doppelbuchungs-Problem wartet.