In einem veröffentlichten Produktions-Workflow, der hauptsächlich mit Google APIs arbeitet, erhalte ich häufig den Fehler:
Forbidden – vielleicht überprüfen Sie Ihre Anmeldedaten?
Quota exceeded for quota metric ‘Queries’ and limit ‘Previous quota: Requests per minute’ of service ‘drive.googleapis.com’ for consumer ‘project_number:…’
Allerdings läuft der Workflow immer problemlos, wenn ich in die Instanz gehe und ihn manuell ausführe.
Es gibt einen geplanten „Master"-Workflow, der den folgenden Workflow ausführt, und wenn dieser zum Knoten „Find REPORTS Folder
@hinzzx die Fehlermeldung besagt, dass Google das Kontingentlimit für die API erreicht hat – es gibt mehrere verschiedene Limits, in diesem Fall ist es das Pro-Minute-Limit, daher könnten mehrere Elemente zum Node gehen. Eine mögliche Lösung wäre, die Retry-Option zum Node hinzuzufügen oder die Fehlerausgabe zu nutzen, eine Wartezeit hinzuzufügen und den Node dann erneut auszuführen.
Jons zweite Option ist diejenige, die hier funktioniert. Gut zu wissen, dass retry bereits auf diesen Knoten in deinem JSON vorhanden ist, maxTries 5 bei 5000ms, was ungefähr 25 Sekunden Wiederholung ist und alles fällt in das gleiche 60-Sekunden-Fenster, das bereits erschöpft ist. Deshalb hilft es nicht. Die Fehlerausgabe plus ein Wait länger als eine Minute bringt dich über eine Pro-Minute-Quote hinaus.
Das Problem ist, dass deine Loop einen Client gleichzeitig ausführt, mit etwa 75 Sekunden Wartezeit für jeden Client, sodass es nicht viele Drive-Aufrufe pro Minute macht. Es lohnt sich, die Projektnummer in der Fehlermeldung zu überprüfen. Wenn du Drive mit „Mit Google anmelden
Hi @Lopez Die VAT & PAYROLL-Prozesse werden an verschiedenen Tagen ausgelöst (zwischen dem 1. und 15. des Monats von 13:00 bis 16:00 Uhr), und die REPORTS werden vom 21. bis 31. des Monats um 17:00 Uhr ausgelöst.
Ich vermute, die Verwirrung könnte von den Screenshots stammen.
Der Ablauf ist 1.–15. des Monats (zwischen 13:00 und 16:00 Uhr) → VAT & PAYROLL Workflows ausführen
21.–31. des Monats (um 17:00 Uhr) → REPORTS Workflow um 17:00 Uhr ausführen.
Damit ist es geklärt, danke. Die beiden Zeiten sind 1 Uhr mittags und 4 Uhr, und 5 Uhr, also können sie nicht am gleichen Tag sein, auch nicht in einem Monat, in dem beide Datumsgrenzen überschritten werden. Meine Theorie über Kollisionen war falsch, also ignoriere den Staffelungsvorschlag.
Das hinterlässt das echte Muster: WF3 schlägt jedes Mal fehl, wenn der Zeitplan es auslöst, und funktioniert jedes Mal, wenn du es zwei Minuten später manuell ausführst, einschließlich des 12-Minuten-Laufs am 21., der deutlich mehr Drive-Aufrufe machte als der fehlgeschlagene. Das Volumen aus diesem Workflow ist nicht das Problem.
Ein billiger Test, der das sauber trennen würde: Verschiebe den REPORTS-Trigger für einen Tag in eine andere Stunde. Wenn es immer noch fehlschlägt, ist die Tageszeit irrelevant und der Unterschied liegt zwischen geplanter und manueller Ausführung, was ein interessanteres Problem ist als das Kontingent. Es lohnt sich trotzdem, auch die frühere Frage zu beantworten: Welche Projektnummer wird im Fehler angezeigt, und hast du dein eigenes Google-Cloud-Projekt und OAuth-Client für diese Drive-Anmeldedaten erstellt oder verbunden es mit „Mit Google anmelden
Ich habe das alles. Die Knoten sind mit Googles OAuth authentifiziert.
Ich könnte unmöglich das Kontingentlimit erreichen, da ich nur Daten aus Google Sheets abrufe und dann entsprechend dieser Daten in Ordner von Google Drive navigiere, wie Clientname → Reports → 082026 → 082026 → Dateien herunterladen → Versenden
Zwischen jedem dieser Schritte gibt es einen Wait-Knoten, um absolut sicherzustellen, dass wir das Kontingentlimit nicht erreichen.
Bei der Anmeldung mit Google in Cloud wird n8n’s Managed OAuth2 verwendet, daher ist der OAuth-Client n8n’s Projekt, nicht deins, und diese Projektnummer im Fehler gehört ihnen. Der Drive-Bucket pro Minute wird mit anderen Cloud-Nutzern auf diesem Client geteilt. Deine Argumentation zum Call-Volumen ist richtig, nur ist es nicht das Volumen, das zählt, und Wait-Nodes können Aufrufe, die nicht von dir stammen, nicht drosseln. Passt auch zu deinem Timing: 17:00:26 schlägt an beiden Tagen fehl, 17:02 und 17:03 sind an beiden Tagen erfolgreich, und zur vollen Stunde aktivieren sich alle geplanten Tasks.
Die Lösung ist, diese Anmeldedaten zu Custom OAuth2 mit deinem eigenen Google-Cloud-Projekt zu verschieben. Dann gehört der Bucket dir und du kannst ihn bei Bedarf erhöhen. REPORTS vorerst auf 17:07 Uhr zu verschieben könnte helfen, das ist ein anderer Grund als die Staffelungsidee, die ich zurückgenommen habe.
Da es beim geplanten Durchlauf fehlschlägt, aber manuell ein paar Minuten später erfolgreich ist, würde ich dies zunächst nicht als normales Berechtigungsproblem behandeln.
Zwei praktische Überprüfungen, die ich durchführen würde: Protokolliere den genauen Zeitstempel vor jedem Drive-Knoten im untergeordneten Workflow, und cache stabile Ordner-IDs, anstatt Drive bei jedem Durchlauf zu durchsuchen, wenn diese Ordner sich nicht bewegen. Ordner-Such-/Listaufrufe werden leicht übersehen, verbrauchen aber immer noch das gleiche Kontingent.
Wenn du einen Warte-/Wiederholungspfad hinzufügst, würde ich ihn länger als das Kontingentfenster machen und die Client-/Report-ID beibehalten, damit die Wiederholung die gleiche Arbeitseinheit fortsetzen kann, anstatt die ganze Report-Kette erneut zu starten.
