Make · Hilfe

Make: „linked feeder was not found“ beim Fortsetzen?

Unvollständiger Make-Lauf scheitert am Aggregator? Prüfe gespeicherten Laufzustand, Source Module und Vollständigkeit der Daten vor einem Neustart.

Quellenstand: 5. November 2026Redaktion: KAN KAI WORKSRedaktionell aktualisiert:

Kurzantwort

Linked feeder was not found beim Fortsetzen eines Make-Laufs betrifft die Beziehung zwischen Aggregatorquelle und gespeicherter Ausführung. Ein funktionierender neuer Lauf beweist nicht, dass der ältere Zustand fortsetzbar ist. Erhalte zuerst Execution und Nutzdaten, dann vergleiche Modul-IDs, Source Module und Aggregationsbereich mit der damaligen Konfiguration. Prüfe vor jedem Neuaufbau bereits entstandene externe Ergebnisse und die Vollständigkeit aller erwarteten Elemente.

Quellengrundlage: Q1 · Q2 · Q3

Gilt für
Der Ausgangsbericht unterscheidet funktionierende neue Läufe von fehlerhafter Wiederaufnahme. Er bestätigt keinen allgemeinen Plattformfehler; gespeicherte Konfiguration und aktuelle Szenarioversion sind gesondert zu prüfen.
So prüfst du das Ergebnis
Der betroffene Geschäftsvorgang ist vollständig abgeschlossen; alle erwarteten Element-IDs erscheinen genau im vorgesehenen Aggregat, und bereits ausgeführte externe Aktionen werden nicht doppelt erzeugt.
Deine erste Prüfung

Scheitert nur die gespeicherte Wiederaufnahme oder auch ein neuer kontrollierter Lauf?

Ein Make-Szenario läuft normalerweise durch. Nach einem Fehler lässt sich eine unvollständige Ausführung jedoch nicht fortsetzen: „linked feeder“ wird für einen Aggregator nicht gefunden. Das ist besonders kritisch, wenn dessen Ergebnis alle Anhänge oder Teildatensätze eines Vorgangs enthalten muss.

Neuer Lauf und gespeicherte Ausführung unterscheiden

Ein Originalbericht beschreibt diese Situation zwischen Iterator, Verarbeitung und Aggregator; neue Läufe funktionierten, das Fortsetzen scheiterte trotz plausibel ausgewähltem Source Module. Eine bestätigte allgemeine Lösung wird daraus nicht abgeleitet. Q1 Make dokumentiert, dass Aggregation von einer bestimmten Quelle ausgeht. Bei unvollständigen Ausführungen sind gespeicherte Konfiguration und Wiederaufnahme gesondert zu betrachten. Q2 Q3

Ein erfolgreicher neuer Test beweist daher noch nicht, dass ein älterer gespeicherter Lauf mit seinem damaligen Zustand fortsetzbar ist. Ebenso wenig beweist ein grünes Endergebnis, dass alle benötigten Elemente darin enthalten sind.

Den gespeicherten Zustand erhalten

  1. Execution und Daten sichern. Notiere die ID der unvollständigen Ausführung, ursprünglichen Fehler, Modul-IDs und erwarteten Geschäftsvorgang. Lösche den Eintrag nicht, solange die darin enthaltene Arbeit noch benötigt wird.
  2. Aggregation bestimmen. Welches Modul soll die Sammlung eröffnen, welches beendet sie, und wie viele eindeutige Eingabeelemente gehören zum Vorgang? Vergleiche diese Erwartung mit der Source-Module-Einstellung und dem sichtbaren Aggregationsbereich.
  3. Laufkonfiguration vergleichen. Wurden Module seit dem Fehler ersetzt, neu angelegt oder umverdrahtet? Vergleiche den gespeicherten Lauf mit dem aktuellen Szenario. Gleiche Modulnamen müssen nicht dieselbe interne ID bedeuten.
  4. Neu- und Wiederaufnahmepfad getrennt testen. Verwende eine Kopie mit harmlosen Daten und abgetrennten externen Schreibaktionen. Dokumentiere, ob nur die Wiederaufnahme scheitert oder bereits die normale Aggregation falsche Mengen liefert.
  5. Supportfall gezielt vorbereiten. Bleibt der Feederfehler trotz nachvollziehbarer Zuordnung bestehen, übergib Execution-ID, betroffene Module, anonymisierten Blueprint und minimalen Reproduktionsweg. Behaupte keinen bestätigten Plattformbug, bevor der Fall eingeordnet ist.

Fachlich vollständige Wiederherstellung

Entscheide für jeden gespeicherten Vorgang, ob eine kontrollierte Fortsetzung oder ein abgeglichener Neuaufbau erforderlich ist. Bereits entstandene externe Ergebnisse müssen dabei berücksichtigt werden. Ein Ignore- oder Ersatzdatenpfad ist ungeeignet, wenn dadurch benötigte Inhalte fehlen und das Szenario trotzdem Erfolg meldet.

Häufige Fragen

Reicht ein neuer Aggregator?

Das kann einen neuen Lauf verändern, repariert aber nicht automatisch den Zustand einer gespeicherten Ausführung. Bewahre diese zunächst auf.

Wann ist das Problem gelöst?

Wenn der konkret betroffene Geschäftsvorgang vollständig und ohne doppelte Wirkung abgeschlossen ist. Vergleiche dafür die erwarteten Element-IDs mit dem tatsächlichen Aggregat, nicht nur den grünen Szenariostatus.

Unterstützung für diesen Fall

Wir helfen dir, den betroffenen Ablauf einzugrenzen und die nächste Maßnahme kontrolliert vorzubereiten. Fall A0371 mit KAN KAI WORKS besprechen.

Unterstützung bei diesem Fehler

Wir prüfen Make anhand deiner Fehlermeldung, Versionen und eines abgegrenzten Beispiels.

Fall beschreiben →Passende Leistung: KI & Automatisierung

Quellen

Quellen geprüft am 5. November 2026. Einzelfallberichte belegen keine allgemeine Verbreitung.