Vertex Gemini 3.8 Flash fails after the first ARTEMIS tool-calling turn

[arislee1979-afk]

Summary

In ARTEMIS's Flash mobile workflow using Vertex AI gemini-3.8-flash, the first model turn succeeds and ARTEMIS executes a UI action. When ARTEMIS sends the tool result for the next model turn, Vertex returns:

400 Requests ending with a model turn are not supported

The task then fails before it can complete.

Reproduction

1. Configure the ARTEMIS Flash route to use Vertex AI gemini-3.8-flash.
2. Run a multi-step Android UI task, for example: open Settings, open Battery, and report the displayed charge level.
3. ARTEMIS receives a model response and performs the first UI action.
4. On the follow-up model request after that action, observe the 400 error above.

Expected result

ARTEMIS continues the tool-calling loop after returning the tool result and completes the task.

Actual result

The first action is executed, but the follow-up Vertex request fails with HTTP 400 and the task stops.

Comparison and investigation

• The same battery task completed with Vertex AI gemini-2.5-flash.
• The 3.8 error also appeared in another recorded multi-step task.
• Increasing the timeout and adding a separate HumanMessage before the follow-up did not resolve it.
• The available ARTEMIS traces do not contain the serialized request payload, so the exact request shape that Vertex rejected has not been confirmed.

Could you advise whether the current ARTEMIS/LangChain Vertex request conversion is expected to work with this model and what sanitized request/trace details would help diagnose the 400?

[arislee1979-afk]

Resolution update

The failure was in ARTEMIS's Vertex request serialization. After an ARTEMIS tool call, its history contains a tool result and a new screen observation. LangChain's Vertex adapter converts the tool result to functionResponse and merges adjacent user messages, producing [functionResponse, text]. Vertex Gemini 3 rejects that part order.

Appending another HumanMessage at the end did not fix it. LangChain merged the additional text into the same user content, still after functionResponse.

The local fix normalizes only the outbound message copy for Vertex Gemini 3. It places screen-observation text before tool results and leaves the stored conversation history unchanged. The fix is in ARTEMIS's shared LLM wrapper, so both Flash and Pro use it. The regression test runs the messages through LangChain's Vertex serializer and checks the resulting part order. The relevant LLM and Flash runner test set passed (49 tests).

A follow-up battery task using Vertex gemini-3.8-flash completed after two tool actions. The final screenshot showed the Battery page at 84%. The run made 3 model calls and took about 32 seconds. This validates the multi-turn continuation for this task; the Settings app had restored its previous Battery page, so the run did not test navigating to Battery from a fresh Settings screen.

The code change is currently in a local working copy and has not been merged upstream. Related independent reports document the same Vertex part-order failure and the accepted alternatives: CLIProxyAPI #5607 and Kimi Code #2913.

[arislee1979-afk]

Clarification to the validation note above: the Trace records pressing Home, launching Settings, and then reporting the result. It does not record a separate tap on Battery. The final screenshot is on the Battery page and shows 84%. This validates a successful Gemini 3.8 follow-up after tool actions, but it does not test fresh navigation to Battery from an arbitrary Settings screen.