Self Checks
RAGFlow workspace code commit ID
(unknown — deployed via Docker image v0.27.0)
RAGFlow image version
v0.27.0
Other environment information
Deployed via Docker on a Linux sandbox (WSL2/Docker Desktop origin, running on remote Linux sandbox), CPU with AVX2/AVX512 support.
Chat model provider: Groq (openai/gpt-oss-20b)
Embedding model provider: Ollama (nomic-embed-text)
Actual behavior
Every chat using the Groq provider fails on the very first message, in a brand-new chat, with or without an associated dataset:
ERROR: INVALID_REQUEST - litellm.BadRequestError: GroqException - {"error":{"message":"messages.1' : for 'role:user' the following must be satisfied[('messages.1' : property 'conversationId' is unsupported)]","type":"invalid_request_error"}} LiteLLM Retried: 5 times
This reproduces consistently across multiple newly created chats. Switching the same chat's model to an Ollama model (e.g. qwen2.5:1.5b) resolves the issue immediately, confirming the problem is specific to the Groq/LiteLLM path.
This appears to be a regression of the class of bug fixed in #15162 ("Fix: /chat/completions not aware of conversation_id"), which was already released in v0.25.6 — well before v0.27.0. Since v0.27.0 shipped a full rewrite of the model provider system (#16604), it's likely that this rewrite reintroduced the same category of issue: an internal parameter (conversationId) not being filtered out before being forwarded to the external Groq API.
Expected behavior
The conversationId (or equivalent internal field) should be filtered out of the payload sent to the Groq API, as was done for the original fix in #15162.
Steps to reproduce
Configure Groq as a chat model provider (e.g. model "openai/gpt-oss-20b")
Create a new chat assistant using this model, with or without an associated dataset
Send any message (e.g. "Hello")
Observe the INVALID_REQUEST / conversationId error
Additional information
Related: #15162 (previously fixed this exact class of bug in v0.25.6), #16604 (v0.27.0 model provider system revamp, likely source of this regression).
Self Checks
RAGFlow workspace code commit ID
(unknown — deployed via Docker image v0.27.0)
RAGFlow image version
v0.27.0
Other environment information
Deployed via Docker on a Linux sandbox (WSL2/Docker Desktop origin, running on remote Linux sandbox), CPU with AVX2/AVX512 support.
Chat model provider: Groq (openai/gpt-oss-20b)
Embedding model provider: Ollama (nomic-embed-text)
Actual behavior
Every chat using the Groq provider fails on the very first message, in a brand-new chat, with or without an associated dataset:
ERROR: INVALID_REQUEST - litellm.BadRequestError: GroqException - {"error":{"message":"messages.1' : for 'role:user' the following must be satisfied[('messages.1' : property 'conversationId' is unsupported)]","type":"invalid_request_error"}} LiteLLM Retried: 5 times
This reproduces consistently across multiple newly created chats. Switching the same chat's model to an Ollama model (e.g.
qwen2.5:1.5b) resolves the issue immediately, confirming the problem is specific to the Groq/LiteLLM path.This appears to be a regression of the class of bug fixed in #15162 ("Fix: /chat/completions not aware of conversation_id"), which was already released in v0.25.6 — well before v0.27.0. Since v0.27.0 shipped a full rewrite of the model provider system (#16604), it's likely that this rewrite reintroduced the same category of issue: an internal parameter (
conversationId) not being filtered out before being forwarded to the external Groq API.Expected behavior
The
conversationId(or equivalent internal field) should be filtered out of the payload sent to the Groq API, as was done for the original fix in #15162.Steps to reproduce
Configure Groq as a chat model provider (e.g. model "openai/gpt-oss-20b")
Create a new chat assistant using this model, with or without an associated dataset
Send any message (e.g. "Hello")
Observe the INVALID_REQUEST / conversationId error
Additional information
Related: #15162 (previously fixed this exact class of bug in v0.25.6), #16604 (v0.27.0 model provider system revamp, likely source of this regression).