Ich denke, hier werden ein paar Dinge durcheinander geworfen.
Ein 503 ist normalerweise ein vorübergehender Fehler auf Googles Seite, aber ich würde ihn nicht automatisch mit Kontingentproblemen oder aggressivem Polling zusammenfassen. Wenn Google denkt, dass du Kontingente überschreitest, siehst du normalerweise 429 oder kontingentbezogene 403 Antworten, nicht 503.
Außerdem bin ich nicht überzeugt, dass die Aktivierung von Retry On Fail notwendigerweise die Antwort ist, wenn der Fehler auf der Ebene des Trigger-Polling selbst auftritt. Trigger-Knoten verhalten sich anders als normale Workflow-Knoten, daher wäre es hilfreich zu bestätigen, ob Wiederholungen tatsächlich auf Google Sheets Trigger-Polling-Fehler angewendet werden oder nur auf nachgelagerte Knotenausführungen.
Die Erklärung zum gemeinsamen OAuth wirkt viel plausibler, besonders da mehrere Nutzer das um die gleiche Zeit zu sehen scheinen. Ein Wechsel zu einem benutzerdefinierten OAuth-Client isoliert dich von gemeinsamen Client-Verhalten und ist wahrscheinlich das erste, das ich testen würde.
Das gesagt, denke ich, dass die wichtigere Frage die ist, die Adam früher gestellt hat:
Ist tatsächlich etwas verloren gegangen?
Wurden Zeilen dauerhaft übersprungen, oder hat das nächste erfolgreiche Polling einfach aufgeholt und sie normal verarbeitet?
Weil es einen großen Unterschied gibt zwischen:
- störenden vorübergehenden 503-Fehlern in den Logs, und
- stillem Datenverlust.
Der erste ist lästig.
Der zweite ist ein Produktionsproblem.
Zum Apps Script-Vorschlag gibt es ein wichtiges Detail, das erwähnt werden sollte:
e.range und e.values funktionieren bei bestimmten Trigger-Typen wie On form submit, sind aber nicht garantiert, dass sie für einen generischen On change installierbaren Trigger existieren. Das Beispiel könnte also für manche Workflows perfekt funktionieren und bei anderen je nach Art des Zeileneintritts sofort fehlschlagen.
Der Webhook-Ansatz ist immer noch attraktiv, weil das Eliminieren von Polling die gesamte Klasse von Polling-Fehlern eliminiert, führt aber stattdessen zu einem anderen Fehlermodus:
Wenn der Webhook-Endpunkt während der Zustellung nicht erreichbar ist, gibt dir Apps Script keine zuverlässigen Wiederholungen oder Warteschlangen.
Personlich würde ich folgendes betreiben:
- Push/Webhook-Zustellung für niedrige Latenz,
- idempotente Verarbeitung mit einer Zeilen-ID,
- und einen geplanten Reconciliation-Workflow, der aktuelle Zeilen regelmäßig neu überprüft.
Push für Geschwindigkeit.
Sweep für Korrektheit.
Diese Kombination übersteht API-Ausfallzeiten, Webhook-Ausfallzeiten, Workflow-Neustarts und ziemlich jeden hässlichen Edge Case, der irgendwann in der Produktion auftaucht.
An diesem Punkt würde ich drei Dinge interessieren, bevor ich Schlussfolgerungen ziehe:
- Gemeinsamer n8n OAuth oder benutzerdefinierten OAuth?
- Wurden tatsächlich Zeilen übersprungen?
- Laufen alle betroffenen Nutzer in der gleichen n8n Cloud-Region oder Infrastruktur?
These Antworten sagen uns wahrscheinlich, ob wir es mit erwarteten Google-Ausfallzeiten zu tun haben oder mit einem tatsächlichen n8n-seitigen Incident, der weiter untersucht werden sollte.