Hallo zusammen,
Ich bin auf ein Problem mit dem OpenAI-Knoten (mit der Operation “Message a Model”) gestoßen und würde gerne Hinweise bekommen, wie ich es beheben kann.
Ich habe den Knoten so eingerichtet, dass er eine einfache Textnachricht versendet. Wie du im beigefügten Screenshot sehen kannst, sind die Parameter ausgefüllt:
Type: Text
Role: User
Prompt: Hi
Aber wenn ich auf “Execute step” klicke, schlägt es mit dieser Ausgabe fehl:
Bad request - please check your parameters
messages must be a non-empty array, got null
Es sieht so aus, als würde der Knoten eine Null-Payload versenden, anstatt des Arrays von Nachrichten, das ich in der UI konfiguriert habe.
Zusätzlicher Kontext:
Ich verwende einen benutzerdefinierten Modellnamen (CSU/PRO/GLM-5.1) über eine benutzerdefinierte Basis-URL.
Hat jemand diesen UI-Fehler oder das Problem mit der Payload-Formatierung schon mal erlebt? Gibt es einen Workaround, um sicherzustellen, dass der Knoten die Nachrichten korrekt in das JSON-Array verpackt?
Vielen Dank im Voraus für deine Hilfe!
Welche Fehlermeldung wird angezeigt (falls vorhanden)?
Bitte teile deinen Workflow
(Wähle die Knoten auf deiner Canvas aus und verwende die Tastaturkürzel CMD+C/STRG+C und CMD+V/STRG+V, um den Workflow zu kopieren und einzufügen.)
Teile die vom letzten Knoten zurückgegebene Ausgabe
@CuO ich glaube, ich kann das jetzt tatsächlich eingrenzen. Ich habe mich da tiefer reingefuchst, und n8ns v2 message a model zielt auf OpenAIs neuere Responses API ab, die den Prompt in einem Input-Feld sendet, nicht in einem Messages-Array. Dein Custom Gateway spricht mit ziemlich hoher Sicherheit nur die ältere Chat/Completions API, bekommt also einen Body ohne Messages-Key und reicht das eins zu eins durch, kriegt null raus – also liegt es nicht wirklich an deiner Config. Es gibt zwei Möglichkeiten: Nutze den Legacy OpenAI Node (1.4, der trifft immer noch Chat/Completions), wenn du die Node-Version wählen kannst, oder nimm den HTTP Request Node direkt zu deinem Gateways /chat/completions mit dem Messages Array. Gleiche v2 Responses-API Root Cause wie in diesem gelösten Thread
Dies ist ein bekanntes Verhalten, das gelegentlich bei der Verwendung von benutzerdefinierten Base-URLs und benutzerdefinierten Modellnamen (wie CSU/PRO/GLM-5.1) auftritt, da die interne Validierungslogik des Knotens das benutzerdefinierte Modell möglicherweise nicht erkennt, was dazu führt, dass ein unvollständiges oder leeres Payload gesendet wird:
1)In neueren n8n-Versionen wurde die Base URL von den Knotenparametern zu den Credentials-Einstellungen verschoben.
Gehen Sie zu Credentials →→ Wählen Sie Ihre OpenAI-Berechtigung aus.
Stellen Sie sicher, dass die Base URL dort eingegeben wird (z. B. https://your-proxy-url.com/v1).
Wichtig: Stellen Sie sicher, dass Sie das Suffix /v1 einschließen, falls Ihr Anbieter dies erfordert, da einige Gateways Anfragen ohne dieses Suffix nicht korrekt weiterleiten.
2)Der Modellname CSU/PRO/GLM-5.1 enthält Schrägstriche. Einige Versionen des OpenAI-Knotens versuchen, den Modellnamen anhand einer bekannten Liste oder eines /models-Endpunkts zu validieren. Wenn die Validierung fehlschlägt oder der benutzerdefinierte Name einen Parsing-Fehler auslöst, kann der Knoten die Payload-Konstruktion „aufgeben