What
When a provider request fails, the user sees the raw response body and nothing about where the request went. In a real session the whole visible failure was:
That names no provider, no SDK, and no URL — the three things needed to act on it.
The information already exists
The durable message record carried it the entire time:
"error": {
"name": "APIError",
"data": {
"message": "404 Page not found",
"statusCode": 404,
"responseBody": "404 page not found",
"metadata": { "url": "https://api.minimax.chat/v1/messages" }
}
}metadata.url is the single fact that turns an opaque failure into a diagnosis — it is what revealed the request had gone to the Anthropic /v1/messages path (see #28). It is persisted but never surfaced.
Suggestion
For provider transport errors, show the resolved provider, model, and request URL alongside the response. A 404 from a plain-text load balancer is otherwise indistinguishable from a wrong API key, a wrong model id, or a wrong host — and here it was none of those, but a resolution bug.
Related: #28, which is the specific defect this opacity concealed.
What
When a provider request fails, the user sees the raw response body and nothing about where the request went. In a real session the whole visible failure was:
That names no provider, no SDK, and no URL — the three things needed to act on it.
The information already exists
The durable message record carried it the entire time:
metadata.urlis the single fact that turns an opaque failure into a diagnosis — it is what revealed the request had gone to the Anthropic/v1/messagespath (see #28). It is persisted but never surfaced.Suggestion
For provider transport errors, show the resolved provider, model, and request URL alongside the response. A 404 from a plain-text load balancer is otherwise indistinguishable from a wrong API key, a wrong model id, or a wrong host — and here it was none of those, but a resolution bug.
Related: #28, which is the specific defect this opacity concealed.