fix(http-client-python): raise azure-core error types for customized errors covering standard status codes

[l0lawrence]

Problem

When a TypeSpec operation declares a customized error model that covers one of the standard azure-core status codes (401, 404, 409, 304), the Python emitter did not always raise the dedicated azure-core error type:

• Ranged error (e.g. 4XX) covering a standard code → fell through to a generic HttpResponseError.
• Default error model (covers all non-success codes) → raised the typed error (via map_error) but without the deserialized error body.

Fix

For status codes 401 → ClientAuthenticationError, 404 → ResourceNotFoundError, 409 → ResourceExistsError, 304 → ResourceNotModifiedError, the generated client now deserializes the customized error body first and then raises the dedicated azure-core error type with that body attached.

• Ranged custom error: emit typed raises for standard codes within the range, after deserialization.
• Default custom error: exclude the standard codes from error_map (so map_error doesn't pre-empt), deserialize the default body, then raise the typed error with the body. Codes already handled inline by a non-default error are skipped to avoid dead code.
• Single/multi specific-code custom errors and the no-custom-error path are unchanged.

Example generated output (ranged + default)

if response.status_code not in [204]:
    map_error(status_code=response.status_code, response=response, error_map=error_map)
    error = None
    if 494 <= response.status_code <= 499:
        error = _failsafe_deserialize(_models.ErrorInRange, response)
    else:
        error = _failsafe_deserialize(_models.DefaultError, response)
    if response.status_code == 401:
        raise ClientAuthenticationError(response=response, model=error)
    if response.status_code == 404:
        raise ResourceNotFoundError(response=response, model=error)
    if response.status_code == 409:
        raise ResourceExistsError(response=response, model=error)
    if response.status_code == 304:
        raise ResourceNotModifiedError(response=response, model=error)
    raise HttpResponseError(response=response, model=error)

Validation

• Regenerated all Azure + unbranded spector specs (181 specs, 0 failures).
• response-status-code-range mock-api tests pass (sync + async, 4/4), exercising both an in-range code and the single 404 → ResourceNotFoundError with the custom body.
• Added a fix changelog entry for @typespec/http-client-python.

[github-actions]

❌ There is undocummented changes. Run chronus add to add a changeset or click here.

The following packages have changes but are not documented.

• ❌typespec-vs

The following packages have already been documented:

• ✅ @typespec/http-client-java
• ✅ @typespec/http-client-python
• ✅ @typespec/http-specs
• ✅ @typespec/openapi3

Show changes

@typespec/http-client-python - feature ✏️

Support datetime.timedelta for duration types encoded as seconds or milliseconds. SDK users can now pass a datetime.timedelta (instead of a raw int/float) and responses are deserialized back into datetime.timedelta.

@typespec/http-client-python - internal ✏️

Add sync and async mock_api tests for the service/multiple-services Spector scenario and enable its regeneration.

@typespec/http-specs - internal ✏️

Add encode/duration lossy Spector scenarios verifying a duration whose value carries more precision than the target integer encoding (fractional seconds and sub-millisecond milliseconds) is serialized as an integer

@typespec/openapi3 - fix ✏️

Fix OpenAPI import to emit @cookie decorators for cookie parameters, including nullable and type-null schema variants.

@typespec/http-client-python - fix ✏️

Fix UnboundLocalError for paging operations with a flattened JSON model body. The request body is now constructed once outside the prepare_request callback (and before the body is serialized into the request content) instead of inside the closure, where assigning body made it an unbound local on every page fetch.

@typespec/http-client-python - fix ✏️

Fix Sphinx docstring rendering when a Required. (or other) annotation followed a code block. The annotation is now inserted into the prose before the code block instead of being appended after it.

@typespec/http-client-python - internal ✏️

Use specific exception types in status code range mock_api tests for sync and async

@typespec/http-client-java - internal ✏️

Add e2e tests for parameters/body-root, parameters/query special char, type/model/inheritance/single-discriminator no-subtypes, azure/resourcemanager/common-properties arm-resource-identifiers, and azure/resourcemanager/management-group scenarios

@typespec/http-client-java - dependencies ✏️

Update Node.js dependencies to latest (compiler 1.13.0, TCGC 0.69.0, azure-core 0.69.0) and bump version to 0.9.0

@typespec/http-specs - fix ✏️

Fix the dollar-sign query scenario route to match the mock API.

@typespec/http-client-python - internal ✏️

Add sync and async mock_api tests for the management group scoped resources and ARM resource identifier Spector scenarios from azure-http-specs.

@typespec/http-client-python - internal ✏️

Add mock API test for the Parameters_Query_SpecialChar_dollarSign Spector scenario.

@typespec/http-client-python - fix ✏️

Raise the dedicated azure-core error type for standard status codes (401, 404, 409, 304) whenever a customized error model covers them (ranged or default error responses), instead of falling back to a generic HttpResponseError or raising without the error body. The error body is now deserialized into the customized error model first and attached to the raised error. For example, a 401 covered by a custom error model now raises ClientAuthenticationError with the customized error body shape.

@typespec/http-client-python - internal ✏️

Refactor Node usage in Python emitter to make it browser bundleable