anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Mistral models fail with "Unexpected role 'user' after role 'tool'" error on custom hosted vLLM endpoint. #4530

New Issue
Open
opened 2026-02-16 17:44:29 -05:00 by yindo · 3 comments
yindo commented 2026-02-16 17:44:29 -05:00
Owner
Copy Link
Copy Source

Originally created by @dfischer-mw on GitHub (Jan 9, 2026).

Originally assigned to: @rekram1-node on GitHub.

Description:

When using Mistral or Devstral models with tool calls (especially via vLLM or openai-compatible providers), requests fail with:

  mistral_common.exceptions.InvalidMessageStructureException:
  Unexpected role 'user' after role 'tool'

This happens because Mistral enforces strict message ordering requiring an assistant message between tool results and subsequent user messages.

This affected in testing only Devstral Small but may extend to other mistral models as well. The expected behaviour should be that the tool calls and assistant messages are enforced to be in the correct order not receiving InvalidMessageStructureException.

Because I also host vLLM, I can confirm the problem is not server sided, vLLM simply rejects the request because of the wrong order.

Originally created by @dfischer-mw on GitHub (Jan 9, 2026). Originally assigned to: @rekram1-node on GitHub. **Description:** When using Mistral or Devstral models with tool calls (especially via vLLM or openai-compatible providers), requests fail with: ```bash mistral_common.exceptions.InvalidMessageStructureException: Unexpected role 'user' after role 'tool' ``` This happens because Mistral enforces strict message ordering requiring an assistant message between tool results and subsequent user messages. This affected in testing only Devstral Small but may extend to other mistral models as well. The expected behaviour should be that the tool calls and assistant messages are enforced to be in the correct order not receiving `InvalidMessageStructureException`. Because I also host vLLM, I can confirm the problem is not server sided, vLLM simply rejects the request because of the wrong order.
yindo commented 2026-02-16 17:44:30 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jan 9, 2026):

This issue might be a duplicate of existing issues. Please check:

  • #6346: Devstral via LiteLLM OpenAI-compatible fails with invalid_request_message_order on first file edit

Both issues describe the same underlying problem with Mistral/Devstral models enforcing strict message ordering that requires assistant messages between tool results and subsequent user messages. Feel free to ignore if this case has specific differences.

@github-actions[bot] commented on GitHub (Jan 9, 2026): This issue might be a duplicate of existing issues. Please check: - #6346: Devstral via LiteLLM OpenAI-compatible fails with invalid_request_message_order on first file edit Both issues describe the same underlying problem with Mistral/Devstral models enforcing strict message ordering that requires assistant messages between tool results and subsequent user messages. Feel free to ignore if this case has specific differences.
yindo commented 2026-02-16 17:44:30 -05:00
Author
Owner
Copy Link
Copy Source

@cmcdowell03 commented on GitHub (Jan 29, 2026):

I am getting the same error when Compaction tries to run with the Devstral models, it bricks the conversation and the messages need reverted to somewhat recover. Then a new session needs to be opened to continue.

@cmcdowell03 commented on GitHub (Jan 29, 2026): I am getting the same error when Compaction tries to run with the Devstral models, it bricks the conversation and the messages need reverted to somewhat recover. Then a new session needs to be opened to continue.
yindo commented 2026-02-16 17:44:30 -05:00
Author
Owner
Copy Link
Copy Source

@Gordonei commented on GitHub (Jan 30, 2026):

Seeing the same bug using OpenAI-compatible API served up by llama.cpp

@Gordonei commented on GitHub (Jan 30, 2026): Seeing the same bug using OpenAI-compatible API served up by llama.cpp
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#4530
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?