fix: correct per-operation tracing lifecycle and HTTP transport edge cases

[OmarAlJarrah]

Summary

Follow-up correctness fixes on top of the HTTP-stack hardening in #6.

Pipeline tracing

The per-operation HttpTracer lifecycle (operation_started / operation_succeeded / operation_failed) was emitted by TracingPolicy, which sits inside the retry and redirect wrappers and is re-entered once per attempt/hop. With the lifecycle gated on the first attempt, a call that failed on its first attempt and then succeeded on a retry emitted operation_failed and never operation_succeeded — and a redirect whose later hop failed emitted operation_succeeded. The reported operation outcome did not match what the caller actually observed, which skews error-rate / SLO telemetry for any retried or redirected request.

A per-attempt policy that runs inside the wrappers cannot know whether a given failure will be retried, so the fix separates the two scopes the HttpTracer interface already implies:

• OperationTracingPolicy (new) sits at a new outermost Stage.OPERATION, outside the redirect/retry wrappers, so a single entry brackets the whole operation. It emits operation_started before the chain and exactly one operation_succeeded / operation_failed on the final outcome.
• TracingPolicy keeps its per-attempt span and per-request events (request_sent, response_headers_received, response_received).

Behavior change for hand-built pipelines. Moving the lifecycle out of TracingPolicy means a pipeline that lists TracingPolicy on its own no longer emits operation_started / operation_succeeded / operation_failed; it emits only the per-attempt span and per-request events. This is intentional and unavoidable — a per-attempt policy cannot produce a correct operation outcome, so the lifecycle has to live in a separate outer policy. default_pipeline wires both, so callers using it are unaffected; callers composing policies by hand should add OperationTracingPolicy alongside TracingPolicy. So the change is not silent, a TracingPolicy that runs with a real HttpTracer but no OperationTracingPolicy bracketing it logs a one-time warning.

Async tracing

The async pipeline already emitted attempt-level tracer events (AsyncRetryPolicy → attempt_started / attempt_failed, AsyncRedirectPolicy → request_url_resolved) but had no operation lifecycle at all, so an async operator saw attempts and redirect hops with no operation_started bracket and no final outcome. Because the HttpTracer callbacks are synchronous, AsyncOperationTracingPolicy (new) mirrors OperationTracingPolicy at Stage.OPERATION, and default_async_pipeline wires it as the outermost policy — completing the async lifecycle so it matches the sync stack. The per-attempt OpenTelemetry span policy (TracingPolicy) and LoggingPolicy remain sync-only.

Regression tests cover exception-retry→success and redirect-then-late-hop-failure on both the sync and async stacks.

Transports & utilities

• urllib: no longer drops a valid Content-Length under Content-Encoding. http.client does not decode content encodings, so the served body is the wire payload whose length equals Content-Length; the header is accurate and is surfaced. (The decompressing requests/httpx/aiohttp adapters still drop it, correctly.)
• urllib + asyncio: report Invalid status code for an out-of-range status, matching the other adapters.
• asyncio: match the chunked transfer-coding by token, not substring, so a coding like x-chunked is not mistaken for chunked framing.
• Share one cross-origin helper (http.common.url._origin) between the redirect and auth policies instead of duplicating it.

Testing

uv run pytest -q → 1412 passed, uv run mypy --strict clean, uv run ruff check / ruff format --check clean. The committed API surface baseline is regenerated for the new OperationTracingPolicy and AsyncOperationTracingPolicy.

🤖 Generated with Claude Code