LLM Node Fails with "has no attribute 'startswith'" when System Prompt is Set

[momo123321111]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

I am trying to use the LLM node (specifically with Qwen3.5-plus-chat) in my workflow. When I leave the SYSTEM prompt field empty, the node runs successfully. However, as soon as I add any content to the SYSTEM prompt (e.g., "123"), the node fails immediately.
It was frustrating because the error message indicated a code-level issue rather than a user input error, making it difficult to debug on my end

2. Additional context or comments

Error Message: PluginInvokeError: {"args": {"description": "[Models] Error: 'TextPromptMessageContent' object has no attribute 'startswith'", "error_type": "InvokeError", ...}}
Reproduction: This happens consistently whenever a System Prompt is set. It works fine with no System Prompt.
Hypothesis: The error suggests that the code is trying to call the .startswith() method directly on the TextPromptMessageContent object instead of on the string content within that object. This appears to be a bug in the plugin's pre-processing logic when handling system messages.

[dosubot[bot]]

This is a known bug in Dify 1.13.1. The root cause is that SystemPromptMessage.content is expected to be a string, but after deserialization it becomes a list[TextPromptMessageContent], causing code that calls .startswith() to fail.

Workarounds until a fix is released:

1. Move content from System Prompt to User Prompt — Dify applies proper JSON conversion to User Prompts but not System Prompts, so this avoids the serialization issue.

2. Update your LLM plugins — Check if newer versions of your model's plugin are available that include fixes for this issue.

A fix is being worked on in PR #2762 which adds normalization helpers to properly handle TextPromptMessageContent objects before provider-specific conversion. It's been tested but not yet merged.

To reply, just mention @dosu.

---

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