[Bug/Limitation] Vertex AI returns 400 Bad Request after receiving sub-workflow tool response — root cause: n8n always returns array instead of object

Description

I am using an AI Agent node in n8n with Vertex AI (Gemini) as the chat model, combined with a sub-workflow tool called search_rag that searches a Qdrant vector database.

Every time the AI Agent calls the tool and receives the response back, the agent immediately fails with:

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

There are no additional error details — no stack trace, no field-level error from Google.


Root Cause Identified

After extensive debugging, I identified the following root cause:

1. Vertex AI/Gemini requires functionResponse to be a JSON object {}, not a JSON array []

Gemini API has stricter requirements than OpenAI regarding the format of functionResponse. Specifically, Gemini expects the tool response to be an object, not an array. When the sub-workflow returns [{...}] (array containing an object), Gemini identifies this as an invalid payload and returns a 400 error at the request validation step — before the model even processes the content. This is why the 400 error is “silent” with no field-level details.

2. n8n sub-workflow always returns an array — this cannot be changed

This is n8n’s default behavior: all workflow outputs are wrapped in an array [{...}]. The only way to return an object instead of an array in n8n is to use Respond to Webhook with First Incoming Item — but this approach cannot be applied to sub-workflow tools inside an AI Agent.

3. LangChain serializes the wrong format for Vertex AI

The n8n Agent node uses a LangChain wrapper to communicate with Vertex AI. LangChain serializes the tool output into a JSON string and places it into functionResponse, but if the top-level structure is an array, some versions of the Vertex AI SDK reject it at the validation step before the model processes it.


Concrete Example

What the sub-workflow currently returns (array — invalid for Vertex AI):

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

What Vertex AI expects (object — valid):

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


What Has Been Confirmed

  • The sub-workflow executes successfully and returns a valid response
  • The error occurs after the Agent receives the tool response, not before
  • The error occurs in both cases: when results are found AND when no results are found
  • There are no null or undefined values in the response
  • Vertex AI does not require a specific field name — message, result, output are all acceptable
  • Vertex AI does not prohibit nested arrays — searchResults: [...] inside an object is fine
  • The only constraint is: top-level must be an object {}, not an array []

Questions

  1. Is there any way to make an n8n sub-workflow tool return a JSON object instead of a JSON array for Vertex AI?
  2. Is this a known limitation of the n8n + Vertex AI integration?
  3. Does the n8n team have plans to fix the LangChain wrapper to automatically unwrap the array into an object when used with Vertex AI?

Hi @nguyenthieutoan
The array never reaches Vertex. The Vertex sub-node runs on @langchain/google-common, which parses the tool output and sends it as functionResponse.response = { content: <output> }, so the top level is already an object whether the sub-workflow returns [{...}] or {...}. The 400 on the turn after a tool call is the Gemini 3.x thought_signature: the model puts a signature on the functionCall part, n8n doesn’t pass it back, and Vertex rejects the next request. The node only surfaces the status code, which is why the error looks empty. The 2.5 models don’t require the signature, so set Model Name on your Google Vertex Chat Model node to gemini-2.5-flash and the tool loop completes. To stay on a 3.x model, use the Google Gemini Chat Model node with an AI Studio key, that endpoint doesn’t enforce it.
See this:

What do you think?

@nguyenthieutoan — If you’re looking for a clean way to keep your current workflow setup without hitting the Gemini 3.x signature validation issue, swapping out the Vertex node for the Google Gemini Chat Model node via AI Studio API key is usually the quickest fix that preserves full model capability.

Alternatively, if you need to stay strictly on Google Cloud / Vertex AI for enterprise compliance, you can route the tool response through a lightweight HTTP Request wrapper node before returning it to the Agent payload to retain the full context window.

If you get stuck, or need help setting up something make sure to dm me.

Thanks for letting us know about this, We have created CV-37 as the internal dev ticket to look into it.

Thanks for letting us know about this, We have created AI-2668 as the internal dev ticket to look into it.

Additional information for you: this error only started appearing after I updated to version 2.31.x (it might also happen on 2.29.x or 2.30.x, but I am not sure, because when I was using version 2.28.7, this error did not occur).

I have no idea how I can accurately track which specific version will include a fix for this kind of issue.