[Bug/Limitation] Vertex AI retorna 400 Bad Request após receber resposta de ferramenta de sub-workflow — causa raiz: n8n sempre retorna array em vez de object

Perguntas
, , , , ,
1

Descrição

Estou usando um nó AI Agent no n8n com Vertex AI (Gemini) como modelo de chat, combinado com uma ferramenta de sub-workflow chamada search_rag que pesquisa um banco de dados de vetores Qdrant.

Cada vez que o AI Agent chama a ferramenta e recebe a resposta de volta, o agente falha imediatamente com:

Bad request - please check your parameters Google request failed with status code 400

Não há detalhes de erro adicionais — nenhum rastreamento de stack, nenhum erro em nível de campo do Google.

Causa Raiz Identificada

Após depuração extensiva, identifiquei a seguinte causa raiz:

1. Vertex AI/Gemini requer functionResponse como um objeto JSON {}, não um array JSON []

A API do Gemini tem requisitos mais rigorosos do que o OpenAI em relação ao formato de functionResponse. Especificamente, o Gemini espera que a resposta da ferramenta seja um objeto, não um array. Quando o sub-workflow retorna [{...}] (array contendo um objeto), o Gemini identifica isso como um payload inválido e retorna um erro 400 na etapa de validação de requisição — antes mesmo do modelo processar o conteúdo. É por isso que o erro 400 é “silencioso” sem detalhes em nível de campo.

2. Sub-workflow do n8n sempre retorna um array — isso não pode ser alterado

Este é o comportamento padrão do n8n: todas as saídas de workflow são encapsuladas em um array [{...}]. A única maneira de retornar um objeto em vez de um array no n8n é usar Respond to Webhook com First Incoming Item — mas essa abordagem não pode ser aplicada a ferramentas de sub-workflow dentro de um AI Agent.

3. LangChain serializa o formato errado para Vertex AI

O nó Agent do n8n usa um wrapper LangChain para se comunicar com o Vertex AI. LangChain serializa a saída da ferramenta em uma string JSON e a coloca em functionResponse, mas se a estrutura de nível superior for um array, algumas versões do SDK do Vertex AI a rejeitam na etapa de validação antes do modelo processá-la.

Exemplo Concreto

O que o sub-workflow atualmente retorna (array — inválido para Vertex AI):

[
{
"message": "Found 3 result(s) for collection_type: media.",
"searchResults": [...],
"count": 3
}
]

O que o Vertex AI espera (objeto — válido):

{
"message": "Found 3 result(s) for collection_type: media.",
"searchResults": [...],
"count": 3
}

O Que Foi Confirmado

  • O sub-workflow é executado com sucesso e retorna uma resposta válida
  • O erro ocorre depois que o Agent recebe a resposta da ferramenta, não antes
  • O erro ocorre em ambos os casos: quando resultados são encontrados E quando nenhum resultado é encontrado
  • Não há valores null ou undefined na resposta
  • Vertex AI não requer um nome de campo específico — message, result, output são todos aceitáveis
  • Vertex AI não proíbe arrays aninhados — searchResults: [...] dentro de um objeto é aceitável
  • A única restrição é: o nível superior deve ser um objeto {}, não um array []

Perguntas

  1. Existe alguma maneira de fazer um sub-workflow do n8n retornar um objeto JSON em vez de um array JSON para o Vertex AI?
  2. Esta é uma limitação conhecida da integração n8n + Vertex AI?
  3. O time do n8n tem planos de corrigir o wrapper LangChain para desencapsular automaticamente o array em um objeto quando usado com Vertex AI?
2

Oi @nguyenthieutoan
O array nunca chega ao Vertex. O sub-nó Vertex é executado em @langchain/google-common, que analisa a saída da ferramenta e a envia como functionResponse.response = { content: <output> }, então o nível superior já é um objeto, independentemente de o sub-workflow retornar [{...}] ou {...}. O 400 na rodada após uma chamada de ferramenta é a assinatura thought_signature do Gemini 3.x: o modelo coloca uma assinatura na parte functionCall, o n8n não a retorna, e o Vertex rejeita a próxima solicitação. O nó apenas expõe o código de status, é por isso que o erro parece vazio. Os modelos 2.5 não exigem a assinatura, então defina Model Name no seu nó Google Vertex Chat Model como gemini-2.5-flash e o loop de ferramentas é concluído. Para permanecer em um modelo 3.x, use o nó Google Gemini Chat Model com uma chave do AI Studio; esse endpoint não a impõe.
Veja isto:

O que você acha?

3

@nguyenthieutoan — Se você está procurando uma forma limpa de manter sua configuração de fluxo de trabalho atual sem enfrentar o problema de validação de assinatura do Gemini 3.x, substituir o nó Vertex pelo nó Google Gemini Chat Model via chave de API do AI Studio geralmente é a correção mais rápida que preserva a capacidade total do modelo.

Alternativamente, se você precisa se manter estritamente no Google Cloud / Vertex AI por conformidade empresarial, você pode rotear a resposta da ferramenta por meio de um nó wrapper HTTP Request leve antes de retorná-la ao payload do Agent para reter a janela de contexto completa.

Se você ficar preso ou precisar de ajuda para configurar algo, certifique-se de me enviar uma mensagem direta.

4

Obrigado por nos informar sobre isso. Criamos CV-37 como o ticket interno de desenvolvimento para investigar o assunto.

5

Obrigado por nos informar sobre isso, criamos AI-2668 como ticket interno de desenvolvimento para investigar.

6

Informação adicional para você: esse erro começou a aparecer apenas depois que atualizei para a versão 2.31.x (também pode ocorrer na 2.29.x ou 2.30.x, mas não tenho certeza, porque quando estava usando a versão 2.28.7, esse erro não ocorria).

Não tenho ideia de como posso rastrear com precisão qual versão específica incluirá uma correção para esse tipo de problema.