OpenAI Node - "Message a Model" (v2 Actions) - Ungültige Anfrage - bitte überprüfen Sie Ihre Parameter

Fragen
1

Beschreibe das Problem/den Fehler/die Frage

Es gibt offenbar eine Regression @Bug in der neuesten Version des nativen OpenAI-Knotens (2.3 (Neueste)), wenn das neue v2 Actions-Layout verwendet wird. Speziell beim Auswählen von Ressource: Text → Operation: Message a Model und beim Konfigurieren des Ausgabeformats auf entweder JSON Schema oder JSON Object schlägt der Knoten bei der Ausführung völlig fehl.
Der API-Aufruf im Hintergrund stürzt mit einem 400 Bad Request Fehler von OpenAI ab.

Fehlermeldung:

Ungültiger Wert: ‘input_text’. Unterstützte Werte sind: ‘output_text’ und ‘refusal’.

Die API-Richtlinien von OpenAI schreiben vor, dass auf dieser Ebene des Payload-Objekt-Arrays streng output_text oder refusal erwartet wird.

Was wir getan haben, um das Problem zu testen und zu isolieren:

  1. Ausgabeformat-Umschalter getestet: Wir haben versucht, von JSON Schema (empfohlen) zu einem grundlegenden JSON Object zu wechseln, um die strikte Schema-Erzwingung zu entfernen. Der Fehler trat weiterhin auf und zeigte, dass n8n’s Tool-Calling-/Chat-Wrapper-Layer im Hintergrund den input_text-Parameter hartcodiert oder erzwingt, unabhängig vom gewählten Format.

  2. Message-Rolle-Workarounds getestet: Wir haben versucht, die Benutzereingaben und Systemregeln in einen einzigen System-Nachrichtenblock zu kombinieren, um zu verhindern, dass n8n verschachtelte User-Rollen-Array-Parameter erstellt. Der Knoten erzwang weiterhin die ungültige Payload-Konfiguration.

  3. Über HTTP Request Node überprüft: Um zu beweisen, dass das Problem ein n8n-Knoten-Formatierungsfehler und kein OpenAI-API-Ausfall oder schlechtes Prompt-Design war, haben wir die Anfrage manuell mit einem Standard-HTTP Request Node unter Ziel https://api.openai.com/v1/chat/completions mit der exakt gleichen Payload codiert. Sie wurde ausgeführt und analysierte die JSON perfekt.

Die funktionierende Lösung / Workaround:

Als definitiver Test haben wir eine ältere Version der OpenAI-Integration (Node Version 1.4) aus einem Legacy-Workflow auf die Canvas kopiert. Mit der Legacy-Version 1.4 Knotenstruktur mit identischem Prompt, Parametern und Eingabedaten läuft der Workflow fehlerfrei. Dies deutet auf einen Fehler hin, wie Node Version 2.3 Payload-Rendering für OpenAIs neuere Responses API-Endpunkte handhabt.

Wie lautet die Fehlermeldung (falls vorhanden)?

Ungültiger Wert: ‘input_text’. Unterstützte Werte sind: ‘output_text’ und ‘refusal’.

Bitte teile deinen Workflow

(Wähle die Knoten auf deiner Canvas aus und verwende die Tastenkombinationen CMD+C/CTRL+C und CMD+V/CTRL+V, um den Workflow zu kopieren und einzufügen.)

Teile die Ausgabe, die vom letzten Knoten zurückgegeben wird

{
“errorMessage”: “Bad request - please check your parameters”,
“errorDescription”: “Invalid value: ‘input_text’. Supported values are: ‘output_text’ and ‘refusal’.”,
“errorDetails”: {
“rawErrorMessage”: [
“400 - {"error":{"message":"Invalid value: ‘input_text’. Supported values are: ‘output_text’ and ‘refusal’.","type":"invalid_request_error","param":"input[2].content[0]","code":"invalid_value"}}”
],
“httpCode”: “400”
},
“n8nDetails”: {
“nodeName”: “Create post and image”,
“nodeType”: “@n8n/n8n-nodes-langchain.openAi”,
“nodeVersion”: 2.3,
“resource”: “text”,
“operation”: “response”,
“itemIndex”: 0,
“time”: “17/06/2026, 1:41:31 pm”,
“n8nVersion”: “2.23.4 (Self Hosted)”,
“binaryDataMode”: “filesystem”,
“stackTrace”: [
“NodeApiError: Bad request - please check your parameters”,
" at ExecuteContext.requestWithAuthentication (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-core@file+packages+core_@opentelemetry+api@1.9.0_@opentelemetry+exporter-trace-otlp_09b6de71aa48ba17834bf7615757388b/node_modules/n8n-core/src/execution-engine/node-execution-context/utils/request-helper-functions.ts:1368:10)“,
" at processTicksAndRejections (node:internal/process/task_queues:104:5)”,
" at ExecuteContext.requestWithAuthentication (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-core@file+packages+core_@opentelemetry+api@1.9.0_@opentelemetry+exporter-trace-otlp_09b6de71aa48ba17834bf7615757388b/node_modules/n8n-core/src/execution-engine/node-execution-context/utils/request-helper-functions.ts:1711:11)“,
" at ExecuteContext.apiRequest (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/@n8n+n8n-nodes-langchain@file+packages+@n8n+nodes-langchain_6aac9327acd297c90db6397ea0a88739/node_modules/@n8n/n8n-nodes-langchain/nodes/vendors/OpenAi/transport/index.ts:56:19)”,
" at ExecuteContext.execute (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/@n8n+n8n-nodes-langchain@file+packages+@n8n+nodes-langchain_6aac9327acd297c90db6397ea0a88739/node_modules/@n8n/n8n-nodes-langchain/nodes/vendors/OpenAi/v2/actions/text/response.operation.ts:621:18)“,
" at ExecuteContext.router (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/@n8n+n8n-nodes-langchain@file+packages+@n8n+nodes-langchain_6aac9327acd297c90db6397ea0a88739/node_modules/@n8n/n8n-nodes-langchain/nodes/vendors/OpenAi/v2/actions/router.ts:58:25)”,
" at ExecuteContext.execute (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/@n8n+n8n-nodes-langchain@file+packages+@n8n+nodes-langchain_6aac9327acd297c90db6397ea0a88739/node_modules/@n8n/n8n-nodes-langchain/nodes/vendors/OpenAi/v2/OpenAiV2.node.ts:93:10)“,
" at WorkflowExecute.executeNode (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-core@file+packages+core_@opentelemetry+api@1.9.0_@opentelemetry+exporter-trace-otlp_09b6de71aa48ba17834bf7615757388b/node_modules/n8n-core/src/execution-engine/workflow-execute.ts:1053:9)”,
" at WorkflowExecute.runNode (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-core@file+packages+core_@opentelemetry+api@1.9.0_@opentelemetry+exporter-trace-otlp_09b6de71aa48ba17834bf7615757388b/node_modules/n8n-core/src/execution-engine/workflow-execute.ts:1327:11)“,
" at /usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-core@file+packages+core_@opentelemetry+api@1.9.0_@opentelemetry+exporter-trace-otlp_09b6de71aa48ba17834bf7615757388b/node_modules/n8n-core/src/execution-engine/workflow-execute.ts:1778:27”,
" at /usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-core@file+packages+core_@opentelemetry+api@1.9.0_@opentelemetry+exporter-trace-otlp_09b6de71aa48ba17834bf7615757388b/node_modules/n8n-core/src/execution-engine/workflow-execute.ts:2426:11"
]
}
}

Informationen zu deinem n8n-Setup

  • n8n-Version: 2.23.4 (Self Hosted)
  • Datenbank (Standard: SQLite):
  • n8n EXECUTIONS_PROCESS Einstellung (Standard: own, main):
  • n8n wird ausgeführt über (Docker, npm, n8n cloud, desktop app): Docker - Self-hosted
  • Betriebssystem:
2

@bridgewaretech solide Isolation. Root Cause ist die Content-Typisierung der Responses API: Assistant-Role-Messages müssen output_text verwenden, nur user/developer verwenden input_text. Dein input[2] ist eine Assistant-Message (ein vorheriger Turn oder ein angehefteter Chat-Memory Sub-Node), den v2.3 als input_text taggt, daher die 400.

Hilfreich zu wissen: Es tritt nur auf, wenn sich eine Assistant-Message im Input befindet, daher umgeht das Entfernen eines Memory/History Sub-Nodes von diesem Node das Problem (nicht praktikabel, wenn du Kontext benötigst, aber es bestätigt den Trigger). v1.4 vermeidet es, indem es stattdessen chat/completions aufruft, daher sind das und dein HTTP-Workaround die richtigen provisorischen Lösungen.

Bekannte v2-Node-Regression, es lohnt sich, deine saubere Repro zu einem GitHub Issue auf n8n-io/n8n hinzuzufügen, falls noch kein Issue offen ist.

3

Danke @achamm
Wir haben das Issue bereits zu GitHub hinzugefügt.

4

@bridgewaretech Gerne! Du kannst gerne eine der Antworten als Lösung markieren und dir einen schönen Tag! Hoffentlich wird das behoben! Kannst du auch den Issue-Link senden?

5

:police_car_light: Update vom Entwickler / GitHub-Status

Ein kurzes Update zu diesem Thema. Wir haben den Bug direkt bei den Entwicklern auf GitHub eingereicht und sie haben das Problem bestätigt. [GitHub-Link hier]

Hier ist die Notiz/das Update vom Entwickler:

Grundursache: Die v2-Operation „Message a Model