feat(logging): add opt-in session_id and trace_id correlation to JSON log records via contextvars

[deepanshululla]

Relevant issues

Closes #31873

Supersedes #33260 (rebuilt on top of litellm_log_correlation / litellm_internal_staging instead of litellm_oss_staging)

Linear ticket

None

Docs

BerriAI/litellm-docs#645

Pre-Submission checklist

• I have added meaningful tests
• My PR passes all CI/CD checks (e.g., lint, format, unit tests)
• My PR's scope is as isolated as possible; it only solves 1 specific problem

Screenshots / Proof of Fix

This PR adds structured logging fields and does not change LLM provider behavior; proof of fix is via the test suite (see Changes) plus live runs against real provider APIs, no mocks (see verification comments on this PR): a live local proxy (real Postgres, real OpenAI-backed deployment) confirming trace_id/session_id are correctly and consistently stamped across an entire request's logging lifecycle including async spend-tracking/callback dispatch, with no cross-request bleed between two concurrent sessions; and a standalone script confirming direct sync SDK calls (litellm.completion(), streaming and non-streaming, against a real model) never touch the correlation contextvars at all, per this PR's async/proxy-only scoping

Type

Refactoring / New Feature

Changes

Adds opt-in request correlation to litellm's logging, gated entirely behind a single flag, false by default:

litellm_settings:
    request_correlation_in_logs: true
    json_logs: true  # optional - works with plaintext logs too, see below

With the flag on, every log line emitted through the standard litellm loggers automatically includes trace_id and session_id, sourced from Python contextvars, and StandardLoggingPayload (sent to logging integrations like S3 and Langfuse) gets an independent session_id field. With the flag off (default), nothing about existing logging behavior or StandardLoggingPayload's shape changes

The implementation follows the standard Python logging pattern: a CorrelationContextFilter(logging.Filter) subclass stamps each LogRecord with the contextvar values before the formatter runs; the filter itself no-ops unless the flag is on. JsonFormatter already has a loop that promotes arbitrary record.__dict__ entries to first-class JSON fields, so no formatter changes were needed there. This mirrors the existing SecretRedactionFilter pattern in the same module. A new CorrelationPlainFormatter gives plaintext logs (json_logs off) the same [trace_id=... session_id=...] suffix, so the flag has a visible effect regardless of log format

set_trace_id() and set_session_id() are the public API for callers to bind correlation IDs. litellm.litellm_core_utils.litellm_logging.Logging.__init__() already calls both at request start, so every log line emitted during a litellm call inherits the correct IDs with no per-call-site wiring. Contextvars provide natural async isolation: concurrent tasks each see only their own IDs (verified live against 8 concurrent proxy requests, see verification comment)

StandardLoggingPayload gains an independent session_id field, populated from litellm_session_id. This field, and the reordering of trace_id's fallback precedence to favor an explicit litellm_trace_id over litellm_session_id, are both gated behind request_correlation_in_logs: off (default), trace_id's existing session-id-first fallback is preserved exactly as before and session_id stays empty; on, the two fields are genuinely independent

Two issues raised in review are also fixed here: correlation context is now restored after a nested call (e.g. a guardrail's own LLM-as-judge call sharing the same asyncio Task as the outer request) completes, via a captured pre-call value restored in Logging's terminal handlers (contextvars.Token.reset() isn't usable here since a token can only be reset in the exact Context it was created in, and these handlers can run in a different asyncio Task than __init__ did), so it no longer leaks into the outer request's subsequent log lines; and set_trace_id/set_session_id now strip control characters and bound length before storing a caller-controlled id, since a caller could otherwise embed \r/\n/escape sequences to forge fake log entries in plaintext output

_correlation_filter is registered on the module-level stream handler, the JSON exception handler created by _setup_json_exception_handlers(), and any handler passed to _initialize_loggers_with_handler(), so coverage is complete regardless of which code path activates logging

The test helper _JsonCapture is updated to register CorrelationContextFilter on itself so that unit tests exercise the same filter path production code uses

Streaming responses needed separate handling since wrapper_async() deliberately skips restoring context when it returns a stream (so log lines emitted while the caller iterates it still carry the call's ids), but the terminal success/failure handlers a stream dispatches to run on a different Task than the one actually consuming it. CustomStreamWrapper restores the consuming context at every genuine exit point on the async side: natural exhaustion, a raised failure, and explicit aclose(). For a stream the caller abandons without ever exhausting or closing it, a best-effort __del__ hook is the last resort, since real cleanup can't be guaranteed there: __del__ timing is unpredictable (delayed by cyclic GC, not guaranteed at interpreter shutdown). To keep that best-effort hook from doing harm if it fires late, it only restores when the contextvars still hold the ids this call itself set, so it never clobbers a different, still-active call that has since taken over the same Task's context

Scope: async/proxy only in this PR

Review surfaced a genuine bug in the sync path: wrapper() (the sync entry point, litellm.completion()) used the same skip-restore-on-stream behavior as wrapper_async(), but a plain OS thread has no per-call context isolation the way an asyncio Task does, and a thread pool's worker threads are recycled across unrelated requests - so an abandoned sync stream could leave its ids "stuck" on a thread that a pool later hands to a completely different request, misattributing that request's logs. A fix existed and was tested (restore unconditionally in wrapper()'s own finally, before ever handing a stream back), but it does not benefit this feature's primary consumer (the proxy, which only ever calls the async entry point) and adds sync-specific complexity this PR doesn't need to carry.

Instead, request_correlation_in_logs is scoped to the async path only here: Logging.__init__() takes a supports_correlation_logging parameter (default True), threaded down from a new function_setup(..., is_async_call: bool = True) parameter. wrapper() is the one caller that passes is_async_call=False - every other function_setup() call site (wrapper_async(), the router, and proxy/MCP-internal call sites) is already async and keeps the default. With supports_correlation_logging=False, Logging.__init__() never calls set_trace_id()/set_session_id() at all, so a sync call has nothing to leak in the first place - wrapper() is back to its original, pre-review shape with no correlation-specific code. StandardLoggingPayload's own trace_id/session_id fields are unaffected by this scoping either way, since they're a deterministic per-call read of self.litellm_trace_id/self.litellm_session_id, not ambient contextvar state.

Full sync/direct-SDK support (stamping + its own safe-restore mechanism) is deferred to a follow-up PR; the fix and its regression test already exist in this branch's history and can be resurrected there.

Fallback to W3C traceparent/baggage headers

trace_id/session_id previously only resolved from litellm-specific sources: x-litellm-trace-id/x-litellm-session-id headers, a generic x-<vendor>-session-id header, or Anthropic-style metadata.user_id. If none were present, trace_id fell back to an unrelated auto-generated UUID even when the caller already had real distributed-tracing instrumentation sending the actual industry-standard headers for this.

Added a fallback to the W3C Trace Context traceparent header (its trace-id component becomes trace_id) and W3C Baggage baggage header (a session.id entry becomes session_id), so a request already carrying real OpenTelemetry trace context correlates litellm's logs with the same trace in the caller's observability backend instead of an unrelated generated id. Precedence is unchanged for existing sources - explicit litellm headers and the Anthropic metadata path both still win; this fallback only fires when neither found anything. trace_id and session_id are resolved independently here (unlike the existing chain_id mechanism, which uses one shared value for both), since traceparent and baggage are semantically distinct W3C concepts. Parsed directly with no new dependency - both header formats are simple fixed-width/delimited strings.

Verified live against a real proxy: a bare traceparent header produces a log trace_id exactly matching its trace-id component; a traceparent alongside an explicit x-litellm-trace-id header (different value) produces a log showing the explicit header's value, proving precedence (see verification comment).

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Deepanshu seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[greptile-apps]

Greptile Summary

Adds opt-in request correlation for async logging

• Stamps sanitized trace and session identifiers onto structured and plaintext log records using context variables
• Restores correlation state across normal, nested, failed, and streaming request lifecycles
• Adds independent session identifiers to standard logging payloads when enabled
• Resolves W3C traceparent and baggage headers as fallback correlation sources
• Keeps synchronous SDK calls outside ambient correlation handling

Confidence Score: 5/5

The PR appears safe to merge

No blocking failures remain

Important Files Changed

Filename	Overview
litellm/_logging.py	Adds sanitized context-variable storage, log-record filtering, reserved JSON correlation fields, and plaintext correlation formatting
litellm/litellm_core_utils/litellm_logging.py	Binds and restores per-call correlation state and populates independent trace and session fields in standard logging payloads
litellm/litellm_core_utils/streaming_handler.py	Restores consumer correlation state across stream exhaustion, failures, explicit closure, and guarded finalization
litellm/utils.py	Scopes correlation to asynchronous calls and restores caller context after setup failures and completed non-streaming calls
litellm/proxy/litellm_pre_call_utils.py	Adds lower-precedence W3C traceparent and baggage extraction for proxy request correlation
litellm/types/utils.py	Extends the standard logging payload contract with an independent session identifier

_{Reviews (20): Last reviewed commit: "fix(logging): restore correlation contex..." | Re-trigger Greptile}

[codecov]

Codecov Report

❌ Patch coverage is 87.42857% with 22 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
litellm/litellm_core_utils/litellm_logging.py	77.04%	14 Missing ⚠️
litellm/utils.py	75.00%	5 Missing ⚠️
litellm/litellm_core_utils/streaming_handler.py	83.33%	3 Missing ⚠️

📢 Thoughts on this report? Let us know!

[deepanshululla]

Ran a live local verification of this PR against a real Anthropic-backed proxy instance

Bootstrapped the worktree with uv sync --python 3.12 (the default resolver here picks 3.14, which breaks uvloop) and generated the Prisma client. The proxy won't start without a reachable Postgres, even for a config with no DB-backed features, so spun up an isolated throwaway Postgres container on a separate port to avoid touching other local infra, then ran litellm/proxy/proxy_cli.py for real against the haiku model

With request_correlation_in_logs: true and json_logs: true set, a POST /v1/chat/completions request carrying litellm_session_id: verify-session-abc123 produced a JSON log line containing "trace_id": "2a5cbcfa-...", "session_id": "verify-session-abc123", matching exactly what was sent. Restarting the proxy with the flag omitted (the default) and sending the same request shape produced no trace_id or session_id fields anywhere in the log, confirming the flag actually gates the behavior and the session value doesn't leak into logs when it's off

To probe the contextvar isolation claim specifically, fired 8 concurrent requests, each with a distinct litellm_session_id. All 8 came back with their own session_id and a distinct trace_id in the logs, with zero cross-contamination between them. That's the part a single-request test can't cover

The underlying Anthropic calls themselves returned 401 in this sandbox since no live key was configured locally. That's fine for this verification because Logging.__init__, where set_trace_id/set_session_id fire, runs before the provider HTTP call, so correlation stamping is exercised independent of the upstream auth outcome

Two environment notes unrelated to this diff but worth flagging: the dev proxy fails startup entirely without a reachable Postgres rather than degrading gracefully, and uv sync resolves to Python 3.14 by default on at least one machine, which breaks uvloop and needs pinning to 3.12

[codspeed]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing deepanshululla:feature/logging-contextvar-request-correlation-v2 (f07b916) with litellm_internal_staging (b66d4e6)}

[deepanshululla]

Follow-up verification for the plaintext-log and StandardLoggingPayload additions in the latest commit

Ran the same local setup as before (isolated throwaway Postgres, real litellm/proxy/proxy_cli.py, real Anthropic-backed haiku deployment). Two things checked

With json_logs left unset (plaintext mode) and request_correlation_in_logs: true, a request carrying litellm_session_id: plaintext-proxy-session-1 produced a log line ending in [trace_id=4173fa77-a1ba-4464-880a-e23b9f9456e5 session_id=plaintext-proxy-session-1]. Before this change the flag had no visible effect at all in plaintext mode since only the JSON formatter read the stamped record attributes

For StandardLoggingPayload.session_id, drove real litellm.completion() calls (real HTTP request to Anthropic, expected to fail with 401 in this sandbox since no live key is configured, which is fine since the payload gets built on the failure path too) with both litellm_trace_id and litellm_session_id set to different values. With the flag off, trace_id came back as the session id value and session_id came back empty, matching the pre-existing behavior exactly. With the flag on, trace_id came back as the actual trace id and session_id came back as the actual session id, confirming the two fields are independent only once opted in

One thing worth flagging: even with the flag on, if only litellm_session_id is passed (no explicit litellm_trace_id), trace_id still falls back to it before falling back to the generated per-call id, since that's the existing intended fallback chain, just reordered rather than removed. That's expected, not a bug, but worth knowing if you're eyeballing the two fields expecting them to always differ

[veria-ai]

PR overview

All previously flagged issues have been addressed. No open security concerns remain on this pull request.

Security review

No open security issues remain on this pull request.

Fixed/addressed: 7 · PR risk: 0/10

[deepanshululla]

Verification evidence for the two review findings, both addressed in 313e170

Correlation context restoration (Greptile). Simulated the exact scenario flagged: a CustomLogger.log_failure_event registered via litellm.callbacks makes its own nested litellm.completion() call (a stand-in for a guardrail's LLM-as-judge call or an MCP sampling call), both against real Anthropic auth failures so the full failure_handler path runs

session_id_var immediately after nested call finished (inside outer callback): OUTER-session
session_id_var AFTER outer call fully completes:
PASS: correlation context correctly restored at both nesting levels

Also ran the earlier 8-concurrent-request isolation check again (asyncio Task-per-request, the primary use case this PR targets) to confirm the restructure didn't regress it; still zero cross-contamination, matching the original verification comment above

Note this went through two iterations before landing correctly. The first attempt (6c70f42) put the reset at the very top of each handler, before callback dispatch runs - live-testing caught that this resets the outer context too early, so a nested call's own token ends up capturing the wrong baseline. The fix in 313e170 wraps each handler's body in try/finally instead, so the reset only fires once the handler's own callback dispatch - including anything nested it triggers - has actually completed. Leaving both commits in the history since they show the debugging process, but 313e170 is the one that actually holds up

Log injection via unsanitized correlation ids (veria-ai).

>>> set_trace_id('evil\r\n{"level": "CRITICAL", "message": "forged"}')
>>> trace_id_var.get()
'evil{"level": "CRITICAL", "message": "forged"}'  # \r\n stripped, can't forge a fake log line

>>> set_session_id('a' * 1000)
>>> len(session_id_var.get())
256  # bounded

All 225 tests across test_logging.py, test_standard_logging_payload.py, and the litellm_core_utils logging test files pass, and make pre-commit (ruff, ruff-strict-budget, type-discipline-budget, basedpyright-budget, format) is clean

[deepanshululla]

@greptileai please re-review, latest commit fixes the correlation-context-restore placement bug you flagged plus adds coverage for the async_failure_handler path

[deepanshululla]

Round summary: cross-context restoration issue (flagged independently by both veria-ai and Greptile's re-review) fixed in 43c164a

Both reviewers correctly identified that the token-based reset from the previous round (6c70f42/313e170f) breaks whenever async_success_handler or a streaming failure path gets dispatched onto a different asyncio Task than Logging.init ran in - which litellm's real async success path does, via asyncio.create_task -> GLOBAL_LOGGING_WORKER. contextvars.Token.reset() only works in the exact Context it was created in; calling it from a different Task raises ValueError, which the old reset_trace_id/reset_session_id helpers silently swallowed, meaning the restore was a no-op for exactly that path

Verified independently before fixing (not just trusting the report): reproduced the raw contextvars behavior in isolation, then traced litellm's actual dispatch code (litellm/utils.py, litellm/litellm_core_utils/logging_worker.py) to confirm it really does cross a Context boundary

Fix: capture the pre-call value in Logging.init instead of a Token, restore via a plain set_trace_id()/set_session_id() call in 43c164a, which works regardless of which Task calls it - nothing to swallow. reset_trace_id/reset_session_id removed as dead code. Added test_restore_correlation_context_works_across_asyncio_task_boundary, which runs init and the restore in separate asyncio Tasks; confirmed it fails against the prior Token-based commit with the exact silent-swallow failure mode described, and passes against 43c164a

227 tests pass across test_logging.py, test_standard_logging_payload.py, and the litellm_core_utils logging test files. make pre-commit clean

@greptileai please re-review

[deepanshululla]

Round summary: Greptile's third finding ("Restoration targets the wrong context") fixed in 15271c9

The prior fix (43c164a) correctly made the restore work across Task/Context boundaries without raising, but only restored the handler's own (detached, throwaway) Task - never the originating request Task that Logging.init actually ran in. For a successful acompletion(), that meant the caller's own Task kept the just-completed call's trace_id/session_id set indefinitely (e.g. visible to a subsequent nested call made in the same Task)

wrapper()/wrapper_async() in litellm/utils.py now restore the originating Task's context in a finally block once the whole call is done. This required a small mutable holder to carry the constructed Logging instance out to the outer wrapper, since the wrapped body rebinds its own kwargs local via function_setup() (a shared-dict-object approach silently didn't work - confirmed with debug instrumentation before landing on this)

Also removed the idempotency guard on _restore_correlation_context(): with value-based restoration, every distinct Task involved in an attempt needs its own call to actually take effect in that Task's own view of the contextvars, so repeat calls are required now, not just tolerated

Added a regression test that exercises the real success dispatch path via mock_response (no live provider needed) and asserts the test's own task context is restored - fails before this commit, passes after. Ran a broad sweep given the blast radius (client()'s wrapper is used by every SDK call): 493 tests across test_utils.py, test_router.py, test_main_module_header.py, and streaming handler tests, plus 228 logging-specific tests, all passing. make pre-commit clean

@greptileai please re-review

[deepanshululla]

Round summary: Greptile's fourth finding ("Setup failures leak correlation context") fixed in 343cb7a

If function_setup() constructs Logging() (mutating trace_id_var/session_id_var in init) and then raises before returning - e.g. update_environment_variables() throws - neither wrapper() nor wrapper_async() ever receives a logging_obj reference, so the finally-block restore added last round never fires, leaking the failed call's ids into every subsequent log line on that thread/task

function_setup()'s own except block now restores the context itself, using whatever logging_obj it managed to construct before failing. Since function_setup() is shared by both the sync and async wrapper bodies, this one fix covers both paths Greptile's comment mentioned

Added a regression test that monkeypatches Logging.update_environment_variables to raise after construction. Confirmed it fails without this fix (the leaked ids show up directly in the raised exception's own log line - concrete, not inferred) and passes with it

Broader regression sweep again given the touched surface: 722 tests across test_utils.py, test_router.py, test_main_module_header.py, streaming handler tests, and all logging-specific tests, all passing. make pre-commit clean

@greptileai please re-review

[deepanshululla]

Fixed a CI regression from the prior commit (343cb7a) in 07d47bf

The "All Other Providers" job caught it: tests/test_litellm/llms/xai/test_xai_key_fallback.py injects a minimal FakeLogging stand-in (only implementing update_from_kwargs) as litellm_logging_obj for a narrow unit test, bypassing the real Logging class. The prior commit's wrapper()/wrapper_async()/function_setup() code unconditionally called _restore_correlation_context() on whatever ended up in the holder, which doesn't exist on that stand-in - 3 tests failed with AttributeError

Added _restore_correlation_context_if_supported(), a getattr-guarded helper, and used it at all three call sites, since this method is new plumbing specific to this feature and no pre-existing stand-in object is expected to implement it. Confirmed the previously-failing tests/test_litellm/llms/xai/test_xai_key_fallback.py now passes (20/20), plus re-ran the full 826-test broad sweep from the last round, still clean. make pre-commit clean

[deepanshululla]

Round summary: two more findings from the same review round, both fixed in 705e47e

Setup failure logged before cleanup. function_setup()'s except block restored correlation context after logging the exception, so that diagnostic log line was stamped with the doomed call's ids rather than the outer ones. Restore now happens first. Verified with a test capturing the actual emitted log record (not just contextvar state afterward) - fails against the prior commit, passes now

Streaming context restored too early. wrapper()/wrapper_async() restored the originating task's context as soon as a streaming call returned the lazy CustomStreamWrapper, before the caller starts iterating it - so log lines emitted during iteration incorrectly showed the pre-call ids. The finally block now detects a CustomStreamWrapper return value and skips the restore, deferring to the terminal handler that already fires once the stream is actually assembled. Verified with sync + async tests (mock_response + stream=True, no live provider needed) - both fail against the prior commit, pass now

Broader sweep: 829 tests passing across all the same suites as prior rounds. make pre-commit clean

@greptileai please re-review

[deepanshululla]

Round summary: abandoned-stream correlation cleanup, 13a7577

This one is different from the prior six: it doesn't have a clean fix, only a best-effort mitigation, and I said so directly on the thread rather than overclaiming

If a caller returns a streaming response and never fully consumes it (stops early, drops the reference, cancels it), the terminal handler that normally restores the originating task's context never fires. CustomStreamWrapper has no close()/context-manager convention today, so there's no reliable signal for this. Added a del that runs the same restore logic, documented as best-effort: GC timing is unpredictable (cyclic-collection delay, no guarantee at interpreter shutdown, can run on a different thread), so this shortens the leak window in the common case rather than eliminating it

Testing note: real garbage collection turned out to be unreliable to test against directly (per-chunk logging holds a transient executor-thread reference to the wrapper that doesn't clear on a fixed schedule), so the tests call del directly to validate the logic deterministically, plus confirm a broken logging_obj can never make it raise

Asked on the thread whether there's a better idea for a complete fix here; my best alternative (requiring context-manager usage) is a bigger API change than seems warranted for this PR

@greptileai please re-review

[deepanshululla]

Round summary: two more streaming-related findings, both fixed in df6ac7b

Veria AI: even a fully consumed stream never restored the actual consuming thread/task's context - the terminal success dispatch (create_task for async, the shared executor for sync) only ever fixes up whatever detached context it runs in

Greptile: explicit aclose() (client disconnect, router fallback aborting a partial stream) closed the underlying stream without restoring context either

Added CustomStreamWrapper._restore_consumer_correlation_context(), called at every point control genuinely returns to the consumer: the final raise StopIteration/StopAsyncIteration on natural exhaustion (both sync and async paths), _handle_stream_fallback_error (the single shared choke point for all three failure-raising call sites, per its own docstring), and aclose(). del now delegates to the same helper instead of duplicating it

Extended the existing streaming-exhaustion tests to assert the consuming context is restored after the loop completes (not just preserved during iteration), and added a dedicated aclose() test - both confirmed to fail against the prior commit and pass now. Broader sweep: 832 passing, make pre-commit clean

@greptileai please re-review

[deepanshululla]

@greptileai please re-review

[deepanshululla]

@greptileai please re-review

[deepanshululla]

Round summary: one veria-ai finding addressed in 4f6ac4c.

Low: Correlation identifiers bypass credential redaction - CorrelationContextFilter stamps trace_id/session_id onto the log record after SecretRedactionFilter has already run, so a caller-controlled value (via x-litellm-trace-id or a W3C baggage header) shaped like a real credential reached JSON and plaintext logs unredacted. Verified live with a poisoned sk-ant-api03-... trace_id: unredacted before the fix, REDACTED after. Fixed at the single choke point (_sanitize_correlation_id, called by both set_trace_id() and set_session_id()) rather than depending on filter ordering. Added a regression test confirmed to fail on the pre-fix code.

This round also rebased onto the latest litellm_internal_staging (56 more commits) and re-verified all lint/type/test gates. CI is fully green on the rebase push (lint, code-quality, codecov/patch, and every test shard all passed).

[deepanshululla]

@greptileai please re-review - the credential-redaction fix for correlation identifiers is in 4f6ac4c.

[deepanshululla]

@veria-ai please re-review

[deepanshululla]

Round summary: one more veria-ai finding addressed in dc7e40f.

Low: Streaming timeout bypasses context restoration - CustomStreamWrapper.anext() called _check_max_streaming_duration() before entering its try block, so the litellm.Timeout it raises bypassed the except Exception -> _handle_stream_fallback_error restoration path entirely, leaking the timed-out stream's own trace_id/session_id into whatever the consumer's task logs next. Verified live: forced a stream past LITELLM_MAX_STREAMING_DURATION_SECONDS and confirmed the outer context stayed stuck on the stream's own ids before the fix, restored after. Fixed by moving the check inside the try block. Added a regression test confirmed to fail on the pre-fix code.

CI is fully green on this push as well (lint, code-quality, codecov/patch, all test shards).

[deepanshululla]

@greptileai please re-review - the streaming max-duration timeout context-restoration fix is in dc7e40f.

[deepanshululla]

@veria-ai please re-review

[deepanshululla]

Round summary: fixed a real CI failure this push (f07b916), not a review finding.

The prior commit (dc7e40f) moved _check_max_streaming_duration() inside anext()'s try block, which correctly routes a max-duration Timeout through the same dispatch_failure_handlers/failure-logging path every other stream failure already uses. tests/test_litellm/litellm_core_utils/test_max_streaming_duration.py::test_should_raise_on_async_anext_when_exceeded used a plain MagicMock for logging_obj, which broke once that async dispatch path was genuinely exercised for the first time. Made the mock's dispatch_failure_handlers awaitable to match the real Logging class.