fix(server): report backend errors on the Anthropic messages bridge

[Yigtwxx]

POST /v1/messages answered HTTP 200 with an empty text block whenever the backend failed, on
both the non-streaming and the streaming path. A caller — Claude Code, say — sees "the model had
nothing to say" instead of the error.

• Non-streaming: the router response went straight into convert_openai_chat_to_anthropic(),
  which has no error branch and falls into its empty-content path. Every Ollama handler in the
  same class guards this with send_backend_error(); the OpenAI path uses set_error_response().
• Streaming: since fix(server): frame backend errors as SSE events on the streaming path #2975 the OpenAI stream carries a backend failure as a framed
  data: {"error": ...} event. The Anthropic adapter inspects only id, usage and
  choices[0], so it dropped that event and closed the stream with stop_reason: "end_turn".
  It now emits an Anthropic event: error frame and stops there, with no closing message frames.

Verified against llamacpp:vulkan + Tiny-Test-Model-GGUF with a context-overflow prompt:

before: 200 {"content":[{"text":"","type":"text"}],...,"stop_reason":"end_turn"}
after:  400 {"type":"error","error":{"type":"invalid_request_error","message":"request (6009 tokens) exceeds the available context size (4096 tokens), try increasing it"}}

Both new tests in test_ollama.py fail against a build of main and pass with this change;
test_024/test_025 and server_streaming_errors.py still pass.

One open question: backend_error_http_status() covers the same ground as
get_error_status_code() in server.cpp, which is file-local. I kept a local helper rather than
widening that file's API surface, but I'm happy to export it in a header and call it from here
instead — just say which you prefer.

[fl0rianr]

Nice fix overall, especially the sent_error handling to avoid emitting normal closing frames after an Anthropic error event.

One thing I think we should tighten up before merging is the status/error-type mapping. build_anthropic_error() currently only handles 400, 404, and 429 explicitly, so other valid backend errors like 401, 403, 413, 422, 504, or 529 end up as api_error.

There is also a streaming-specific gap: StreamingProxy may expose the backend status as error.status or not add it at all when the backend already returned a structured error object, while backend_error_http_status() only checks status_code and numeric code. That means a streaming 429/5xx can lose its original status and be translated as a generic 500/api_error.

Could we make the backend status propagation consistent, ideally using status_code, and expand the Anthropic error-type mapping accordingly? A small test for a non-400 4xx plus a streaming 429/529 case would cover this nicely.

[Yigtwxx]

Both of these were real, and the second one was worse than described — thanks for pulling on it.

What StreamingProxy actually emits

Two paths, two different shapes:

• Body is not already an {"error": ...} object → it synthesizes one and adds the status under status, not status_code. backend_error_http_status() never looked at status, so this was already broken for every non-400.
• Backend returned its own structured error → it forwards it untouched, adding nothing. llama.cpp happens to include a numeric code, which is the only reason the overflow case in test_027/test_028 maps to 400 at all. Any backend that omits code fell through to 500/api_error.

Measured against llamacpp:vulkan before the change — the backend's own error, forwarded verbatim, with no field the bridge reads:

{"error":{"code":400,"message":"request (6009 tokens) exceeds the available context size (4096 tokens), try increasing it","n_ctx":4096,"n_prompt_tokens":6009,"type":"exceed_context_size_error"}}

Standardising on status_code

status_code is already the repo's field — get_error_status_code() in server.cpp reads it, and details.status_code. So both proxy paths now publish it, and a backend's own error object gets it injected when absent:

} else if (payload["error"].is_object() && !payload["error"].contains("status_code")) {
    payload["error"]["status_code"] = status;
}

Same request after the change — same body, plus the transport status:

{"error":{"code":400,"message":"request (6009 tokens) exceeds the available context size (4096 tokens),
try increasing it","n_ctx":4096,"n_prompt_tokens":6009,"status_code":400,"type":"exceed_context_size_error"}}

Two other spots emitted status and are moved over so exactly one name is left in the tree: trellis_server.cpp (image-format rejection), and serve_media_or_error() in server.cpp, which had an inlined copy of the status-extraction loop reading status — that now just calls get_error_status_code(), which is what the helper is for.

Error-type mapping

Expanded to every status Anthropic names, with the remaining 4xx bucketed rather than left as api_error:

status	type		status	type
400	invalid_request_error		429	rate_limit_error
401	authentication_error		500, 502, 504	api_error
403	permission_error		529	overloaded_error
404	not_found_error		other 4xx	invalid_request_error
413	request_too_large

Status extraction now also reads details.status_code, matching get_error_status_code().

On the tests — and why they are C++ rather than Python

I could not write the integration tests you asked for, and the reason is worth stating rather than quietly substituting something else. No in-repo backend can drive build_anthropic_error() to anything but 400:

• A non-400 4xx does not reach it. An unknown model 404s in the auto_load_model catch at anthropic_api.cpp:996, well before set_anthropic_backend_error_response(); anything that throws lands in the outer catch as a hardcoded 500/api_error. The only status that reaches the mapping from a real backend is llama.cpp's 400.
• 429 and 529 have no producer at all. Nothing in server_models.json rate-limits or reports overload; those come from cloud providers, which need credentials CI does not have.

So the mapping was untestable where it lived. The two helpers move to src/cpp/include/lemon/anthropic_error.h and get a cpp-ci unit test — AnthropicErrorTest, 26 cases covering 401/403/413/422/429/504/529 and the status_code / details.status_code / code / type-fallback extraction order. ctest -L cpp-ci goes 25/25 → 26/26.

That header is also the answer to the open question in the PR description: backend_error_http_status() is no longer a private duplicate sitting in a .cpp. Merging it with get_error_status_code() outright is a bigger change — that one is used by ~20 handlers and has no code fallback — so I have left them separate. Happy to do that consolidation as a follow-up if you want it.

Verification

• ctest -L cpp-ci: 26/26 (was 25/25).
• test_027 / test_028 and the whole server_streaming_errors.py suite (7/7, including test_004a from fix(server): frame backend errors as SSE events on the streaming path #2975, which asserts on this exact SSE payload): pass against a rebuilt lemond on llamacpp:vulkan + Tiny-Test-Model-GGUF.
• Rebased onto main at 756d94ba, so fix(server): return the router error status on rerank, slots and tokenize #2974 is now in the base.

(Comment drafted with AI assistance, per docs/dev/contribute.md.)

[fl0rianr]

The status propagation changes look good now, thanks. I think there’s just one mapping gap left: Anthropic currently defines 402 -> billing_error, 409 -> conflict_error, and 504 -> timeout_error. Right now 402/409 fall through to invalid_request_error, while the new test explicitly expects 504 to be api_error. Could we add those three mappings and corresponding test cases? After that this looks good to me.

[Yigtwxx]

Added in 8dc69e6f. All three are documented in the errors reference — 402 billing_error, 409 conflict_error, 504 timeout_error — and you're right that the previous commit got 504 wrong: {504, "api_error"} was an incorrect assertion on my side, not an intentional choice, so I've corrected the expectation rather than kept it.

build_anthropic_error() now names every status Anthropic names; 4xx values it doesn't name still fall through to invalid_request_error, and unnamed 5xx to api_error.

Test rows added for 402 and 409, and the 504 row flipped to timeout_error. Each of the three was red before the header change (402/409 resolved to invalid_request_error, 504 to api_error). AnthropicErrorTest is 28/28.

[fl0rianr]

LGTM, thanks