Environment
- Self-hosted image:
diegosouzapw/omniroute:3.8.51-web
- Any strict OpenAI-compatible upstream (Cerebras, Mistral, Groq observed)
What happens
When a client sends user messages whose content blocks carry a non-standard field (here: message_id, emitted by a popular chat client during context compaction), OmniRoute forwards the unknown field verbatim during wire-format translation. Strict validators then reject the entire request:
- Cerebras:
400 — property 'messages.2.user.message_id' is unsupported
- Mistral:
422 — extra_forbidden
- Groq:
400 — role:user constraint
Example request shape:
{
"model": "...",
"messages": [
{"role": "user", "content": [
{"type": "text", "text": "...", "message_id": "msg_01ABC"}
]}
]
}Impact
In a priority combo, one such request cascades: every strict-validator target burns (400/422 each), latency spikes, and the request only lands on a lenient wrapper (antigravity/nvidia tolerate extra fields) — or fails entirely. We observed ~1,948 client aborts (499) in 6h from a single client doing periodic compaction.
Suggested fix
When translating between wire formats (client format → upstream OpenAI/Anthropic format), strip unknown fields from content blocks rather than forwarding them — or sanitize per upstream validator. Unknown top-level message fields like message_id are client metadata and shouldn't reach providers.
Happy to provide full gateway logs of the cascade.
Environment
diegosouzapw/omniroute:3.8.51-webWhat happens
When a client sends user messages whose content blocks carry a non-standard field (here:
message_id, emitted by a popular chat client during context compaction), OmniRoute forwards the unknown field verbatim during wire-format translation. Strict validators then reject the entire request:400 — property 'messages.2.user.message_id' is unsupported422 — extra_forbidden400 — role:user constraintExample request shape:
{ "model": "...", "messages": [ {"role": "user", "content": [ {"type": "text", "text": "...", "message_id": "msg_01ABC"} ]} ] }Impact
In a priority combo, one such request cascades: every strict-validator target burns (400/422 each), latency spikes, and the request only lands on a lenient wrapper (antigravity/nvidia tolerate extra fields) — or fails entirely. We observed ~1,948 client aborts (499) in 6h from a single client doing periodic compaction.
Suggested fix
When translating between wire formats (client format → upstream OpenAI/Anthropic format), strip unknown fields from content blocks rather than forwarding them — or sanitize per upstream validator. Unknown top-level message fields like
message_idare client metadata and shouldn't reach providers.Happy to provide full gateway logs of the cascade.