Function classify_service_error 

pub fn classify_service_error(
    status: u16,
    body: &str,
    message: impl Into<String>,
    retry_after: Option<f64>,
) -> Error

Classify a non-success OpenAI-wire (Chat Completions / Responses) HTTP response into a granular Error.

The single point of truth for status/body interpretation, used by every endpoint in this crate (OpenAIChatCompletionClient::post and responses) and reused by agent-framework-azure (Azure OpenAI is wire-compatible for Chat Completions and Responses), so the two stay identical rather than drifting.

Mirrors upstream’s openai/_chat_client.py / _responses_client.py:

except BadRequestError as ex:
    if ex.code == "content_filter":
        raise OpenAIContentFilterException(...)
    raise ServiceResponseException(...)

for the content-filter case, and extends upstream’s exception hierarchy — ServiceInvalidAuthError / ServiceInvalidRequestError already exist in agent_framework.exceptions, even though today’s Python OpenAI client folds every other status (auth failures included) into that same generic ServiceResponseException — to also classify by HTTP status:

• 401 / 403 -> Error::ServiceInvalidAuth
• 400 / 404 / 422 -> Error::ServiceInvalidRequest, unless the body signals a content-filter refusal (error.code or error.type == "content_filter", checked at the top level and inside a nested innererror for Azure OpenAI’s shape) -> Error::ServiceContentFilter
• anything else — notably 408 / 429 / 5xx, which RetryOn::Default depends on — -> Error::ServiceStatus, unchanged

body is parsed leniently as JSON purely to look for the content-filter marker; a non-JSON or differently-shaped body just skips that check and falls through to the plain status-based classification, so this never panics or itself errors. message is used verbatim as the resulting error’s text (callers already format a provider-specific “OpenAI API error 400: …” string; this only picks the variant).