API-Datenänderungen während eines langen n8n-Workflows

Fragen
1

Hey Leute, ich habe einen n8n-Workflow, der Tausende von Datensätzen aus einer externen API mit Pagination abruft.
Das Problem ist, dass sich der Datensatz ändern kann, während der Workflow läuft. Neue Datensätze können eingefügt werden, und bestehende Datensätze können zwischen Seitenanfragen aktualisiert oder gelöscht werden.
Zum Beispiel:
GET /customers?page=1
GET /customers?page=2
GET /customers?page=3
…
Bei offset-basierter Pagination mache ich mir Sorgen, dass Datensätze übersprungen oder doppelt verarbeitet werden könnten, wenn sich der Datensatz zwischen Anfragen ändert.
Würdet ihr stattdessen cursor-basierte Pagination verwenden?
Wie würdet ihr APIs handhaben, die nur page + limit unterstützen und keinen Cursor oder Snapshot-Token bereitstellen?

Problem/Fehler/Frage beschreiben

Wie lautet die Fehlermeldung (falls vorhanden)?

Bitte teilt euren Workflow

(Wählt die Knoten auf eurer Canvas aus und verwendet die Tastaturkürzel CMD+C/STRG+C und CMD+V/STRG+V, um den Workflow zu kopieren und einzufügen.)

Gibt die Ausgabe des letzten Knotens an

Informationen zu eurem n8n-Setup

  • n8n-Version:
  • Datenbank (Standard: SQLite):
  • n8n EXECUTIONS_PROCESS-Einstellung (Standard: own, main):
  • n8n läuft über (Docker, npm, n8n cloud, Desktop-App):
  • Betriebssystem:
2

Hallo @Catherine, während du auf eine Antwort wartest, findest du hier einige hilfreiche Ressourcen:

Empfohlene Ressourcen

Automatisch an deine Frage angepasst.

Dokumentation:

Forum:

@achamm, @sbruner, @om-Juri - ihr habt bei ähnlichen Problemen schon geholfen, könntet ihr mal einen Blick darauf werfen?

Automatisch vorgeschlagen von n8n’s Community-Bot. Das ist ein Pilotprojekt – bitte teilt euer Feedback hier mit.

3

Hallo @Catherine ich würde kursorbasierte Pagination bevorzugen, wann immer die API dies unterstützt. Offset-Pagination kann unzuverlässig werden, wenn während des Durchblätterns der Seiten Datensätze eingefügt oder gelöscht werden.

Ein Cursor gibt dir eine stabile Position:
Seite anfordern
Datensätze verarbeiten
Next_cursor abrufen
Nächste Seite anfordern
Wiederholen

Zum Beispiel:

return [{
json: {
cursor: $json.next_cursor,
hasMore: Boolean($json.next_cursor)
}
}];

Wenn die API nur page und limit unterstützt, würde ich versuchen, den Datensatz durch Sortierung nach einem unveränderlichen Feld wie id deterministisch zu machen:
GET /customers?limit=500&sort=id&order=asc

Noch besser, wenn die API Filterung nach ID unterstützt, verwende keyset-basierte Pagination:
GET /customers?after_id=5000&limit=500

Speichere auch die zuletzt verarbeitete ID/den Cursor in PostgreSQL, damit der Workflow nach einem Fehler fortgesetzt werden kann, ohne von Seite 1 neu zu beginnen.

4

Hi @Catherine Sortieren nach ID wird das Offset-Pagination-Problem nicht lösen, wenn Datensätze gelöscht werden. Wenn Seite 1 die IDs 1 und 2 zurückgibt und ID 1 gelöscht wird, kann Seite 2 bei ID 4 beginnen und 3 überspringen.

Ich würde Cursor-/Keyset-Pagination bevorzugen, aber ein Cursor gibt dir nicht automatisch einen Snapshot der Daten.

Mit nur page + limit kannst du keine vollständige, konsistente Leseoperation garantieren, während sich die Quelle ständig ändert. Hole die Daten in eine Staging-Tabelle, bevor du die langsame Verarbeitung durchführst, dedupliziere mit Datensatz-ID und Quellversion, wo verfügbar, und führe dann Abgleichsdurchläufe durch. Das reduziert die Auswirkungen, aber Deduplizierung kann Datensätze, die du nie erhalten hast, nicht wiederherstellen. Behandle einen fehlenden Datensatz nicht als Beweis dafür, dass er gelöscht wurde.

Welche API ist das? Für strikte Konsistenz müssten wir überprüfen, ob sie einen Snapshot/Export oder einen Change Feed mit Löschungen bietet.

5

@Anshul_Namdev hat recht: Das Sortieren nach ID bei Offset-Pagination verhindert nicht, dass Datensätze übersprungen werden, wenn Zwischenzeilenlöschungen auftreten.

Kritik der Community-Antwort

Emmas: Befürwortet zu Recht Cursor-Pagination, liegt aber falsch darin, dass Sortieren nach ID die Offset-Pagination-Drift während Löschungen eliminiert.

Anshul_Namdev: Weist zu Recht darauf hin, dass Löschungen Offsets unabhängig vom Sortieren verschieben, und empfiehlt korrekt Staging-Tabellen, Deduplizierung oder Bulk-Snapshots.

Natives n8n-Setup
Implementieren Sie Pagination nativ im n8n HTTP Request Node unter „Add Option > Pagination

6

Hey @Catherine, kurze Antwort auf beide Fragen: ja, nutze einen Cursor, falls die API einen hat, und mit nur page + limit nutze den Staging- und Reconciliation-Ansatz, den Anshul beschrieben hat.

Eine Sache, die ich noch hinzufügen würde: Das Abrufen von Tausenden von Datensätzen auf diese Weise ist ein langwieriger Workflow, und an diesem Punkt ist Pagination nur die halbe Miete. Die andere Hälfte ist der Workflow-Status: Es ist wichtig zu verfolgen, welche Batches tatsächlich gespeichert wurden und wo ein fehlgeschlagener Durchlauf sicher fortgesetzt werden kann.

Die Reihenfolge, in der du Dinge speicherst, ist hier wichtig. Wenn der Workflow den „zuletzt verarbeitet