OpenAI Node - "Message a Model" (v2 Actions) - Requête invalide - veuillez vérifier vos paramètres

Questions
1

Décrire le problème/erreur/question

Il semble y avoir une régression @Bug dans la dernière version du nœud OpenAI natif (2.3 (Latest)) lors de l’utilisation de la nouvelle mise en page v2 Actions. Spécifiquement, lors de la sélection Resource: Text → Operation: Message a Model et de la configuration du Output Format sur JSON Schema ou JSON Object, le nœud échoue complètement à l’exécution.
L’appel API en arrière-plan plante avec une erreur 400 Bad Request d’OpenAI.

Message d’erreur :

Invalid value: ‘input_text’. Supported values are: ‘output_text’ and ‘refusal’.

Les directives API d’OpenAI stipulent que celle-ci s’attend strictement à output_text ou refusal à ce niveau du tableau d’objets de charge utile.

Ce que nous avons fait pour tester et isoler le problème :

  1. Tests des basculements Output Format : Nous avons essayé de passer de JSON Schema (recommended) à un JSON Object basique pour supprimer l’application stricte du schéma. L’erreur s’est toujours produite, ce qui montre que la couche wrapper d’appel d’outil/chat d’arrière-plan de n8n force ou code en dur le paramètre input_text quel que soit le format choisi.

  2. Tests des contournements Message Role : Nous avons essayé de combiner les entrées utilisateur et les règles système en un seul bloc de message System pour empêcher n8n de créer des paramètres de tableau de rôle User imbriqués. Le nœud a toujours forcé la configuration de charge utile invalide.

  3. Vérification via HTTP Request Node : Pour prouver que le problème était un bug de formatage du nœud n8n et non une panne de l’API OpenAI ou une mauvaise conception d’invite, nous avons codé manuellement la requête à l’aide d’un nœud HTTP Request standard ciblant https://api.openai.com/v1/chat/completions avec la même charge utile exacte. Il s’est exécuté et a analysé le JSON parfaitement.

La solution/contournement fonctionnant :

Comme test définitif, nous avons copié une version antérieure de l’intégration OpenAI (Node Version 1.4) d’un workflow hérité dans le canevas. En utilisant la structure du nœud version 1.4 hérité avec l’invite, les paramètres et les données d’entrée identiques, le workflow s’exécute impeccablement. Cela pointe vers un bug dans la façon dont Node Version 2.3 gère le rendu de charge utile pour les points de terminaison Responses API plus récents d’OpenAI.

Quel est le message d’erreur (le cas échéant) ?

Invalid value: ‘input_text’. Supported values are: ‘output_text’ and ‘refusal’.

Veuillez partager votre workflow

(Sélectionnez les nœuds sur votre canevas et utilisez les raccourcis clavier CMD+C/CTRL+C et CMD+V/CTRL+V pour copier et coller le workflow.)

Partagez la sortie renvoyée par le dernier nœud

{
“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"
]
}
}

Informations sur votre configuration n8n

  • Version de n8n : 2.23.4 (Self Hosted)
  • Base de données (défaut : SQLite) :
  • Paramètre n8n EXECUTIONS_PROCESS (défaut : own, main) :
  • Exécution de n8n via (Docker, npm, n8n cloud, application de bureau) : Docker - Auto-hébergé
  • Système d’exploitation :
2

@bridgewaretech isolation solide. La cause racine est le typage du contenu de l’API Responses : les messages de rôle assistant doivent utiliser output_text, seuls user/developer utilisent input_text. Votre input[2] est un message assistant (un tour précédent ou un sous-nœud de mémoire de chat attaché) que v2.3 étiquette comme input_text, d’où le 400.

Indice utile : cela se déclenche seulement quand un message assistant est dans l’entrée, donc supprimer un sous-nœud de mémoire/historique de ce nœud le contourne (pas viable si vous avez besoin du contexte, mais cela confirme le déclencheur). v1.4 l’évite en utilisant chat/completions à la place, donc cela et votre contournement HTTP sont les bons intérimaires.

Régression connue v2-node, vaut la peine d’ajouter votre repro propre à un problème GitHub sur n8n-io/n8n s’il n’y en a pas déjà un ouvert.

3

Merci @achamm
Nous avons déjà ajouté le problème sur GitHub.

4

@bridgewaretech De rien ! N’hésite pas à marquer l’une des réponses comme solution et bonne journée ! Espérons que ça se règle ! Tu peux aussi envoyer le lien du problème ?

5

:police_car_light: Mise à jour du développeur / Statut GitHub

Une mise à jour rapide sur ce sujet. Nous avons signalé le bug directement aux développeurs sur GitHub, et ils ont reconnu le problème. [Lien GitHub ici]

Voici la note/mise à jour du développeur :

Cause racine : l’opération v2 « Message a Model » construit chaque message texte avec une partie de contenu input_text, indépendamment du rôle. L’API Responses d’OpenAI n’accepte que output_text/refusal pour les messages avec le rôle assistant, donc dès qu’un message Assistant se trouve dans la liste, la demande échoue avec :

Invalid value: ‘input_text’. Supported values are: ‘output_text’ and ‘refusal’.

Le format de sortie (JSON Schema / JSON Object) n’est pas vraiment le déclencheur — c’est le message avec le rôle Assistant qui est envoyé en tant que input_text. Le nœud legacy 1.4 fonctionne parce qu’il cible l’ancien point de terminaison chat/completions, qui n’utilise pas ces parties de contenu typées.

Correctif : les messages texte de l’Assistant seront envoyés en tant que contenu en chaîne de caractères simple (que l’API Responses accepte et traite comme sortie texte de l’Assistant) au lieu d’une partie input_text ; les messages utilisateur/système restent inchangés. Une PR avec cette modification plus des tests de régression est en préparation et sera liée ici.

Solutions temporaires en attente du déploiement :

  • Supprimez le(s) message(s) avec le rôle Assistant et intégrez ce contexte dans le message System, ou
  • Restez avec le nœud HTTP Request (ou le nœud 1.4) que vous avez déjà vérifié comme fonctionnel.

:police_car_light: Mise à jour du développeur / Statut GitHub

Conformément à la mise à jour de développement, le correctif a été publié avec n8n@2.29.0