bug: When calling Google models in a multi-turn conversation, an error occurs because `thought_signature` is not included.

[BeautyyuYanli]

Self Checks

• I have read the Contributing Guide and Language Policy.
• This is only for bug report, if you would like to ask a question, please head to Discussions.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed.
• 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
• Please do not modify this template :) and fill in all the required fields.

Dify version

1.11.4

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

This issue can only be reproduced with Nano Banana Pro. It cannot be reproduced with Nano Banana.

Gemini 3 Pro Preview does not have this problem (but Gemini 3 Pro Preview does not support file output). It is recommended to test gemini-2.5-flash-image / gemini-3-pro-image-preview.

Steps to reproduce
Send an image to Nano Banana Pro and have it process the image.
In the same conversation, reply using Nano Banana and ask it to modify the image.

✔️ Expected Behavior

Multi-turn conversations should be processed correctly.

❌ Actual Behavior

Run failed: req_id: 861eb74ff9 PluginInvokeError: {"args":{},"error_type":"ClientError","message":"400 INVALID_ARGUMENT. {'error': {'code': 400, 'message': 'Image part is missing a thought_signature in content position 2, part position 1. Please refer to https://ai.google.dev/gemini-api/docs/thought-signatures#model-behavior for more details.', 'status': 'INVALID_ARGUMENT'}}"}

[dosubot]

This error happens because the Gemini plugin does not capture and replay the actual thought_signature from the Gemini API response in multi-turn conversations. Instead, it uses a static placeholder, which only works for the first image generation. For subsequent turns, the Gemini API requires the exact thought_signature from the previous response; otherwise, it returns a 400 INVALID_ARGUMENT error as described in the Gemini API docs and confirmed in related issues.

To resolve this, update the Gemini plugin to version 0.7.0 or later, which correctly handles thought_signature passthrough for multi-turn conversations (details). If updating is not possible, the only reliable workaround is to start a new conversation for each image generation or use a model that does not require thought_signature (like qwen-max or DeepSeek) for multi-turn tasks.

A permanent fix requires code changes so the plugin and core message model capture, persist, and replay the actual thought_signature from each Gemini response and include it in subsequent requests (reference).

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[BeautyyuYanli]

Proposal: Preserve thought_signature (and similar provider-specific fields) via opaque_body

1) What is thought_signature?

Through testing, we confirm that thought_signature is a signature attached to a specific content part of a model response (e.g., an image content part).
It is required for certain kinds of content parts, and is not a field for the whole response message or the whole conversation thread.

2) Solution overview: introduce opaque_body for pass-through

To solve the problem (and to future-proof against similar provider-specific requirements), introduce an opaque_body field:

• Content-part level: content_part.opaque_body
  Stores provider-specific opaque metadata for that content part (e.g., thought_signature for an image part).
• Message level: message.opaque_body
  Reserves space for provider-specific opaque metadata attached to the message as a whole (if any provider needs it later).
• Behavior contract: opaque_body must be passed through without modification across:
  • Dify api
  • dify-plugin-daemon
  • LLM provider plugins (e.g., Gemini-related plugins)
    This ensures that when the next turn references prior multimodal outputs, all required provider metadata is still available and can be sent back to the provider API.

3) Data persistence & chat history handling in Dify (key focus: Workflow LLM Node)

Dify has multiple code paths that build / transform / store chat history. To make opaque_body truly work, Dify must persist and replay it when reconstructing conversation context.

Key requirement: Workflow LLM Node must store opaque_body (both message-level and content-part-level) into whatever history / state it uses, and include it when assembling the subsequent request payload.

Additionally, any other chat-history handling components should do the same too.

[BeautyyuYanli]

A previous fix for Vertex is a temporary workaround because the plugin instance is desgin to be stateless #2387

[BeautyyuYanli]

• Previous changes of code
  refactor: LLM plugin invoke parsing dify#31499
  fix: Drain non-stream plugin chunk iterator dify#31564
• Support opaque_body for the components
  add message level and content level opaque_body dify-plugin-sdks#284
  feat: support opaque_body from plugin LLM calls dify#31566
  feat: support opaque_body in prompt messages dify-plugin-daemon#585
• Preserving opaque_body for chat history

[dosubot]

This error happens because Google Gemini models (like Nano Banana Pro) require a thought_signature token in the image part of the request payload for multi-turn conversations. The plugin is supposed to capture the thought_signature from the previous Gemini API response and replay it in subsequent requests to maintain context. Right now, the Dify Gemini plugin does not do this—it uses a hard-coded placeholder that only works for the first turn, so the second image request fails with a 400 INVALID_ARGUMENT error from the Gemini API [source].

The main Dify codebase does not build the Gemini API payload; this logic is in the plugin server, and the parameter is not set anywhere in the main repo [source]. There is no official fix or merged pull request for this issue yet—maintainers have mentioned possible bypasses, but nothing is documented or released [source].

To resolve this, the plugin needs to capture and replay the real thought_signature from Gemini API responses as described in the Gemini API documentation. For now, the only workaround is to use a different model (like qwen-max), but this does not support Gemini-specific features [source]. If you need Gemini features, you’ll need to monitor plugin updates or consider contributing a patch that implements proper thought_signature handling.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}