fix(router): bind per-request routing_strategy override selectors to the request's callbacks

[devin-ai-integration]

TLDR

Problem this solves:

• Per-request routing_strategy: least-busy never sees which deployment is busy
• Per-request routing_strategy: latency-based-routing never learns any latency
• Both route blind since fix(router): keep per-request routing_strategy override selectors out of global callbacks #40229, while the configured strategy still works

How it solves it:

• Attach the override selector to that request's own callback list
• It gets pre-call, success and failure for that request only
• Global litellm.*callback lists stay untouched, so no cross-request leak

User Flow

Before: a key whose router_settings say least-busy keeps landing on the deployment that is already streaming

1. They send POST http://localhost:4000/v1/chat/completions with "stream": true against lb-group using a key whose router_settings set routing_strategy: least-busy; the response header says x-litellm-model-id: lb-d1
2. While that stream is still running they send three short POST http://localhost:4000/v1/chat/completions calls to the same group with the same key
3. All three come back 200 with x-litellm-model-id: lb-d1, the one deployment that is busy
4. With routing_strategy: latency-based-routing on a group where one deployment times out (408) and one answers, eight calls in a row keep going back to the timing-out deployment: 408, 408, 200, 200, 200, 408, 408, 408

After: the same requests avoid the busy deployment and settle on the fast one

1. They send the same streaming POST http://localhost:4000/v1/chat/completions; the response header says x-litellm-model-id: lb-d1
2. While that stream is still running they send the same three short calls
3. All three come back 200 with x-litellm-model-id: lb-d2, an idle deployment
4. Once the stream finishes, short calls go back to lb-d1, so the busy mark is released
5. With routing_strategy: latency-based-routing, one 408 on the first pick, then seven 200s in a row from the deployment that answers

Relevant issues

Follow-up to #40229

Affected release

regression since v1.102.0-dev.1 (#40229), present in v1.102.0-rc.1

Linear ticket

Resolves LIT-7682

Root cause and fix

#40229 builds the per-request override selector with register_callbacks=False, which correctly keeps a per-request strategy out of the global litellm.input_callback / success_callback / failure_callback lists. Nothing replaced that registration with a request-scoped one, so LeastBusyLoggingHandler never got log_pre_api_call (in-flight +1) or success/failure (in-flight -1), and LowestLatencyLoggingHandler never got a success or failure timing sample. Both selectors then ranked deployments on an empty map and picked the first one every time

The fix binds the selector to the request:

# litellm/router.py, in _get_routing_context on the override branch
override_selector = self._get_override_strategy_selector(override)
self._bind_override_selector_to_request(override, override_selector, request_kwargs)

def _bind_override_selector_to_request(self, strategy, selector, request_kwargs):
    if selector is None or request_kwargs is None or strategy in self._globally_registered_strategies():
        return
    logging_obj = request_kwargs.get("litellm_logging_obj")
    if isinstance(logging_obj, LiteLLMLogging):
        logging_obj.add_dynamic_callback(selector)

def _globally_registered_strategies(self) -> frozenset[str]:
    # the router's default strategy plus every routing group's strategy: those selectors
    # are already in the global callback lists, so binding a second one would double count

# litellm/litellm_core_utils/litellm_logging.py
def add_dynamic_callback(self, callback: CustomLogger) -> None:
    # appends `callback` (once) to dynamic_input / success / async_success / failure / async_failure callbacks
    # by building fresh lists, never mutating the existing ones

The Logging object already merges litellm.<x>_callback + dynamic_<x>_callbacks at every lifecycle point (pre-call, sync and async success, sync and async failure), so the selector now gets exactly the events it would have received from global registration, scoped to this one request. When the override equals the router's configured strategy, or the strategy of any explicit routing group, a selector for that strategy is already globally registered, so nothing is bound (no double count; a group's selector shares the same per-model-group cache keys as the override selector, so a second one would record every request twice). _get_routing_context is shared by get_available_deployment, async_get_available_deployment and both pass-through variants, so all four entry points are covered. The same binding restores success-time usage recording for the other overridable strategies (usage-based-routing, usage-based-routing-v2, cost-based-routing); only least-busy and latency-based were verified live below

Tests

tests/test_litellm/router_strategy/test_router_routing_groups.py (mapped file) gains eight tests that build the request the way the proxy does (Logging object created before the router sees it):

• async least-busy: a held stream marks d1 busy, override picks d2, draining the stream releases d1
• sync least-busy: same, through router.completion(stream=True)
• least-busy failure path: a failing call releases the in-flight count
• async latency-based: after a timing-out d1, override converges on d2 and every pick has a fresh sample
• the selector is bound only to the request and is absent from every global callback list
• an override equal to the configured strategy binds nothing
• an override equal to a routing group's strategy (simple-shuffle default, latency-based-routing group) binds nothing and the request lands in the latency map exactly once
• binding the same selector twice keeps one copy and requests without a Logging object are left alone

Mutation matrix (one fix line removed at a time, tree restored with cp and checked with cmp -s, focused run -k override, 25 tests): no binding call in the router 5 failed; no configured-strategy guard 1 failed; dropping the input, success, async success, failure or async failure dynamic list 4, 3, 3, 1 and 3 failed respectively. Every mutant is killed; with the fix in place the focused run and the full mapped file (80 tests) pass. Second round, after the group-aware guard: reverting the guard to the default-strategy-only check makes the new routing-group test fail 3 out of 3 runs with assert 2 == 1 (two identical latency samples for one request), and it passes 3 out of 3 with the guard. scripts/pre_commit_lint.sh passes with no budget file changes

tests/test_litellm/litellm_core_utils/test_litellm_logging.py (mapped file) gains one test that calls add_dynamic_callback twice on a Logging object whose success list is caller-owned and checks the caller's list is untouched, every dynamic list holds the callback once, and _with_dynamic_callback handles None and an already-present callback

Taxonomy audit (A-BB)

• W1, W4: _with_dynamic_callback builds a new list from a tuple snapshot, never mutates the caller's list; request_kwargs is read only
• B6: the callback in existing guard means a request that hits _get_routing_context twice (retry helper plus selection) binds the selector once, so one pre-call increment and one release. Review round 1 found the sibling case: a routing group whose strategy matches the override already has a global selector on the same cache keys, so the guard now covers group strategies too (test above)
• F3, O4: sync and async, streaming and non-streaming, success and failure all covered by tests; all four router selection entry points share the changed helper
• C1-C7: no default change; requests without an override never reach the binding (early return), verified live with plain calls still shuffling across all three deployments
• X1: callbacks or () treats None and [] the same on purpose; both mean "no dynamic callbacks yet"
• A1: no new cache; the selector's own state (in-flight counts, latency map) lives in the router cache exactly as it does for the configured strategy
• H: no new source comments, X | None unions, Mapping / Sequence instead of bare dict / list, no docs or dashboard change needed
• T1-T5, T17: every new test fails on unfixed code; assertions are on the served model_id and on cache counters, not on structure; conftest autouse fixtures reset global callbacks

House-rules review of the final diff at a933424 (override string is normalized before the group guard compares it, Mapping / Sequence parameters, Final locals, no mutation of caller state, no new imports into hub modules) found no blocker or major item

Regression sweep

The changed symbols are Logging.add_dynamic_callback (new), Logging._with_dynamic_callback (new), Router._bind_override_selector_to_request (new), Router._globally_registered_strategies (new) and Router._get_routing_context (one extra call). Readers of dynamic_*_callbacks outside litellm_logging.py are litellm/llms/openai/openai.py, litellm/llms/custom_httpx/llm_http_handler.py and litellm/litellm_core_utils/chat_completion_agentic_loop.py (agentic hook discovery over litellm.callbacks + dynamic_success_callbacks), the Rust lifecycle bridge (phase gating), and the two producers that seed the lists before the router runs: function_setup in litellm/utils.py (per-request success_callback / failure_callback kwargs) and the pass-through endpoints (team callbacks). The producers keep owning their lists because the binding builds a new list instead of appending. All of them already iterate router selectors today whenever the configured strategy registers one in litellm.callbacks, so a selector arriving through the dynamic list is not a new shape for them.

/live-pr-risk dependency walk (base 94f0863, head a933424):

• _get_routing_context callers: get_available_deployment, async_get_available_deployment and both pass-through variants (all four go through the one changed line); _get_request_routing_strategy_override is unchanged and still reads routing_strategy from request kwargs, which is what router_settings_override and the key/team router_settings path forward
• dynamic_*_callbacks readers outside the logging module: agentic hook discovery in llm_http_handler.py, openai.py and chat_completion_agentic_loop.py (_has_pre_call_deployment_hook-style checks over litellm.callbacks + dynamic_success_callbacks), the Rust lifecycle bridge phase gating, and _should_run_sync_callbacks_for_async_calls. Each only asks whether a callback overrides a hook method; the router selectors do not override those hooks, so their answers are unchanged with the selector in the list. Verified live: every leg below ran through these readers
• function_setup reuses a litellm_logging_obj already present in kwargs, so the dynamic lists set by the router survive into litellm.acompletion (that is how the live legs receive the events). Retries and fallbacks reuse the same Logging object; the callback in existing guard keeps the binding to one entry
• No config key, response field, DB column or dashboard contract changes; the sibling docs checkout has no reference to these private helpers
• Live A/B at base 94f0863 vs head a933424, both booted from their own tree (PYTHONPATH asserted, MARKER add_dynamic_callback 0 vs 1) with --num_workers 2, one Postgres, real OpenAI, byte-identical fixtures in the same order. Least-busy with a stream held on one worker: base sends all six short calls to the busy lb-d1; head sends the calls that land on the worker holding the stream to lb-d2 (calls 3 and 6) and the ones on the other worker to lb-d1, because least-busy counts are per process without Redis, which is the same shape the configured strategy has today. Latency-based: base 408, 408, 200, 200, 200, 408, 408, 408; head 408, 200, 408, 200, 200, 200, 200, 200 (one cold pick per worker, then every pick on lat-fast); the simple-shuffle control returned 408 on both sides. usage-based-routing, usage-based-routing-v2 and cost-based-routing overrides: nine 200s with real content on each side and spend rows written; on head usage-based-routing now spreads picks (lb-d1, lb-d2, lb-d1) where base pinned lb-d1, which is the restored usage signal. Default routing without an override: six 200s spread over the three deployments on both sides
• Not verified live: the SDK-only path where router.acompletion(..., routing_strategy=...) is called without a pre-built Logging object; there the logging object is created after deployment selection, so the override still runs without its signal exactly as before this PR (no regression, not fixed here)

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have added meaningful tests
• The handful of test files covering my change pass locally, e.g. uv run pytest tests/test_litellm/<your_test_file>.py -v. Leave the suites (make test-unit-*, make test-unit) to CI: it finishes in ~15 minutes where a laptop takes an hour or more
• My PR passes all required CI/CD checks (e.g., lint, schema.d.ts sync check, etc.)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes)

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on Slack (#pr-review).

Screenshots / Proof of Fix

Real proxy (litellm --config config.yaml --port 20682 --use_prisma_db_push, Postgres behind it, PYTHONPATH pinned to the checkout, served tree asserted at launch), real OpenAI calls to gpt-4.1-nano. Same config and byte-identical request files on both sides (sha256 printed by the run). The build that served each side is identified by grep -c add_dynamic_callback litellm/router.py at launch: 0 before, 1 after

model_list:
  - model_name: lb-group
    litellm_params: {model: openai/gpt-4.1-nano, api_key: os.environ/OPENAI_API_KEY}
    model_info: {id: lb-d1}
  - model_name: lb-group
    litellm_params: {model: openai/gpt-4.1-nano, api_key: os.environ/OPENAI_API_KEY}
    model_info: {id: lb-d2}
  - model_name: lb-group
    litellm_params: {model: openai/gpt-4.1-nano, api_key: os.environ/OPENAI_API_KEY}
    model_info: {id: lb-d3}
  - model_name: lat-group
    litellm_params: {model: openai/gpt-4.1-nano, api_key: os.environ/OPENAI_API_KEY, timeout: 0.001, weight: 1}
    model_info: {id: lat-slow}
  - model_name: lat-group
    litellm_params: {model: openai/gpt-4.1-nano, api_key: os.environ/OPENAI_API_KEY, weight: 0}
    model_info: {id: lat-fast}
router_settings:
  routing_strategy: simple-shuffle
  num_retries: 0
  disable_cooldowns: true
general_settings:
  master_key: sk-litfix-7682

lb_stream.json   {"model":"lb-group","messages":[{"role":"user","content":"Write a 1500 word essay on the history of the telegraph."}],"max_tokens":3000,"stream":true,"router_settings_override":{"routing_strategy":"least-busy"}}
lb_short.json    {"model":"lb-group","messages":[{"role":"user","content":"say hi"}],"max_tokens":5,"router_settings_override":{"routing_strategy":"least-busy"}}
lat_pick.json    {"model":"lat-group","messages":[{"role":"user","content":"say hi"}],"max_tokens":5,"router_settings_override":{"routing_strategy":"latency-based-routing","num_retries":0}}
lat_control.json {"model":"lat-group","messages":[{"role":"user","content":"say hi"}],"max_tokens":5,"router_settings_override":{"routing_strategy":"simple-shuffle","num_retries":0}}
lb_plain.json    {"model":"lb-group","messages":[{"role":"user","content":"say hi"}],"max_tokens":5}

The run script is plain sequential curls: open the stream in the background, wait for its x-litellm-model-id header, fire the three short calls, wait for the stream to drain; then eight latency-based calls and one control call

URL=http://127.0.0.1:20682/v1/chat/completions; KEY=sk-litfix-7682
curl -sS -N -D stream_head.txt -o stream_body.txt -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" --data-binary @lb_stream.json "$URL" &
for i in 1 2 3; do curl -sS -o /dev/null -D lb_head_$i.txt -w "%{http_code}" -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" --data-binary @lb_short.json "$URL"; done
wait
for i in $(seq 1 8); do curl -sS -o lat_$i.json -D lat_head_$i.txt -w "%{http_code}" -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" --data-binary @lat_pick.json "$URL"; done
curl -sS -o /dev/null -w "%{http_code}" -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" --data-binary @lat_control.json "$URL"

Before (d2859e1, main at capture time; the two source files this PR touches and the routing path they feed are byte-identical between d2859e1 and the merge base 94f0863)

least-busy override while one deployment is streaming

1. Launch: serving tree: /home/ubuntu/repos/litellm/litellm/__init__.py, MARKER add_dynamic_callback occurrences in router.py: 0
2. Output:

== fixtures (sha256) ==
c745efc8a8e7ec49151fb8cd5930e01644f6339b04247b6b15492883c0531582  lb_stream.json
03c188bb317a926b745bfbce03d01611582ae15d76d3cc30665fb266c87edf62  lb_short.json
df2806fde799c5a7b895a10ac582d4c45c79cd63979a4dc0093ac651f604d888  lat_pick.json
5894a98d4d2d3265d7157a8bcad74119800c1e6945faccc9951720ae31e2981f  lat_control.json

stream opened: x-litellm-model-id=lb-d1  (this deployment is BUSY while the stream runs)
least-busy short call 1 -> HTTP 200  x-litellm-model-id=lb-d1
least-busy short call 2 -> HTTP 200  x-litellm-model-id=lb-d1
least-busy short call 3 -> HTTP 200  x-litellm-model-id=lb-d1
stream status: HTTP/1.1 200 OK
stream drained: 1301 data lines, terminator present: 1

3. All three short calls land on lb-d1, the deployment that is busy streaming

latency-based override with one deployment timing out

1. Output:

latency-based call 1 -> HTTP 408  x-litellm-model-id=
latency-based call 2 -> HTTP 408  x-litellm-model-id=
latency-based call 3 -> HTTP 200  x-litellm-model-id=lat-fast
latency-based call 4 -> HTTP 200  x-litellm-model-id=lat-fast
latency-based call 5 -> HTTP 200  x-litellm-model-id=lat-fast
latency-based call 6 -> HTTP 408  x-litellm-model-id=
latency-based call 7 -> HTTP 408  x-litellm-model-id=
latency-based call 8 -> HTTP 408  x-litellm-model-id=
control (simple-shuffle, weight sits on lat-slow) -> HTTP 408 (expected 408: lat-slow still routable, so fast picks above were not a cooldown)

2. The override keeps returning to lat-slow (408) because no latency sample was ever recorded; the 200s are the unsignaled tie-break happening to land on lat-fast

After (re-captured at the PR tip a933424 with the same fixtures)

least-busy override while one deployment is streaming

1. Launch: serving tree: /home/ubuntu/repos/litellm/litellm/__init__.py, MARKER add_dynamic_callback occurrences in router.py: 1; MARKER _globally_registered_strategies: 2; tip: a933424ed5
2. Output:

== fixtures (sha256) ==
c745efc8a8e7ec49151fb8cd5930e01644f6339b04247b6b15492883c0531582  lb_stream.json
03c188bb317a926b745bfbce03d01611582ae15d76d3cc30665fb266c87edf62  lb_short.json
df2806fde799c5a7b895a10ac582d4c45c79cd63979a4dc0093ac651f604d888  lat_pick.json
5894a98d4d2d3265d7157a8bcad74119800c1e6945faccc9951720ae31e2981f  lat_control.json

stream opened: x-litellm-model-id=lb-d1  (this deployment is BUSY while the stream runs)
least-busy short call 1 -> HTTP 200  x-litellm-model-id=lb-d2
least-busy short call 2 -> HTTP 200  x-litellm-model-id=lb-d2
least-busy short call 3 -> HTTP 200  x-litellm-model-id=lb-d2
stream status: HTTP/1.1 200 OK
stream drained: 1700 data lines, terminator present: 1

3. All three short calls avoid lb-d1 while it streams
4. Three more short calls after the stream drained (in-flight count released):

least-busy short call 1 (stream drained, nothing in flight) -> HTTP 200  x-litellm-model-id=lb-d1
least-busy short call 2 (stream drained, nothing in flight) -> HTTP 200  x-litellm-model-id=lb-d1
least-busy short call 3 (stream drained, nothing in flight) -> HTTP 200  x-litellm-model-id=lb-d1

latency-based override with one deployment timing out

1. Output:

latency-based call 1 -> HTTP 200  x-litellm-model-id=lat-fast
latency-based call 2 -> HTTP 408  x-litellm-model-id=
latency-based call 3 -> HTTP 200  x-litellm-model-id=lat-fast
latency-based call 4 -> HTTP 200  x-litellm-model-id=lat-fast
latency-based call 5 -> HTTP 200  x-litellm-model-id=lat-fast
latency-based call 6 -> HTTP 200  x-litellm-model-id=lat-fast
latency-based call 7 -> HTTP 200  x-litellm-model-id=lat-fast
latency-based call 8 -> HTTP 200  x-litellm-model-id=lat-fast
control (simple-shuffle, weight sits on lat-slow) -> HTTP 408 (expected 408: lat-slow still routable, so fast picks above were not a cooldown)

2. One 408 on the second pick (the first two picks are unsignaled, one per deployment), then the timeout is recorded as a slow sample and every later pick goes to lat-fast. The control call proves lat-slow is still routable, so this is latency learning and not a cooldown

default routing unchanged

1. Twelve calls with lb_plain.json (no override, router default simple-shuffle):

plain call 1 -> lb-d1   plain call 5 -> lb-d2   plain call 9  -> lb-d1
plain call 2 -> lb-d2   plain call 6 -> lb-d2   plain call 10 -> lb-d3
plain call 3 -> lb-d1   plain call 7 -> lb-d2   plain call 11 -> lb-d3
plain call 4 -> lb-d2   plain call 8 -> lb-d1   plain call 12 -> lb-d1

2. All 200, spread across the three deployments as before

Scope of the live proof: /v1/chat/completions through the proxy's router_settings_override body field (the same kwarg the key/team router_settings path forwards), least-busy and latency-based only. The other overridable strategies share the binding but were verified by the unit tests only

Type

🐛 Bug Fix

Caveats (if any)

Low

• Latency-based needs one sample per deployment before it can rank; the first pick after a cold start is still unsignaled
• Selector state for an override still lives in the router-lifetime selector cache from fix(router): keep per-request routing_strategy override selectors out of global callbacks #40229, so counts and latency accumulate across requests on purpose
• usage-based-routing, usage-based-routing-v2 and cost-based-routing overrides were exercised live only for status and pick spread (nine 200s each side, see the regression sweep), not for their ranking math
• The SDK-only override path (no proxy, no pre-built Logging object) is out of scope, see the regression sweep. The per-request override is the proxy's router_settings_override / key and team router_settings feature from fix(router): keep per-request routing_strategy override selectors out of global callbacks #40229, and the ticket's user flow is POST /v1/chat/completions. Making router.acompletion(..., routing_strategy=...) carry its signal in the SDK would mean building the Logging object before deployment selection on every router entry point (chat, embeddings, images, audio, and the rest), which is a separate change with its own blast radius
• The two e2e cells this ticket names (test_least_busy_avoids_deployment_with_request_in_flight, test_latency_based_routes_around_deployment_that_times_out) live in tests/e2e/router/test_reliability_routing_strategies_e2e.py on the still-open test(e2e): cover the reliability retry, cooldown, fallback, and routing-strategy cells #39857, so their skip markers come off there once this lands; the proxy legs above are that scenario replayed against a local proxy

Final Attestation

• The tests check the right things, including the edge cases, and regressions in the respective real-world customer use-cases are not possible after this PR

Link to Devin session: https://app.devin.ai/sessions/d766c096f7614da2b7ecad93fbc71621
Requested by: @yassin-berriai

ran /live-pr-risk and found no regressions/backward incompatible risks

---

Note

Medium Risk
Changes request-scoped router callback wiring and affects deployment selection for per-request strategy overrides; guards limit double registration but routing behavior is business-critical.

Overview
Fixes a regression where per-request routing_strategy overrides (e.g. from key/team router_settings) could pick deployments without seeing in-flight load or latency, because override selectors were built with global callback registration disabled and nothing wired them to the request lifecycle.

When routing resolves to a request override, the router now attaches that override’s strategy selector to the request’s LiteLLMLogging object via new add_dynamic_callback, so pre-call, success, and failure hooks run for that request only. Binding is skipped if the override strategy is already registered globally (router default or any routing group), avoiding double-counting on shared cache keys.

add_dynamic_callback appends the selector once across all dynamic_* callback lists using fresh lists (_with_dynamic_callback), so caller-owned lists are not mutated.

^{Reviewed by Cursor Bugbot for commit f808c68. Bugbot is set up for automated code reviews on this repo. Configure here.}

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[codspeed]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing litellm_request_override_selector_callbacks (f808c68) with main (94f0863)¹}

Footnotes

1. No successful run was found on main (b4cff58) during the generation of this report, so 94f0863 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[greptile-apps]

Greptile Summary

Binds per-request routing-strategy selectors to the request’s logging callbacks so overrides receive lifecycle signals without changing global callback lists.

• Skips request binding when the strategy is already registered through the router default or a routing group.
• Adds coverage for routing signals, callback deduplication, and preservation of caller-owned lists.
• The latest revision only annotates the logging test’s fixture parameter; production code and test assertions are unchanged.
• No new actionable findings remain.

Confidence Score: 5/5

The PR appears safe to merge, with no outstanding findings.

The latest revision resolves the remaining fixture-annotation issue without changing runtime behavior or weakening assertions. The routing-group duplicate-accounting and helper-typing findings are fixed. The SDK-only logging limitation was correctly conceded as pre-existing and outside this fix’s scope.

Important Files Changed

Filename	Overview
litellm/router.py	Request-scoped selector binding includes the group-aware guard that resolves the previous duplicate-accounting finding.
litellm/litellm_core_utils/litellm_logging.py	Adds selectors once to each dynamic lifecycle callback list without modifying caller-owned lists.
tests/test_litellm/router_strategy/test_router_routing_groups.py	Covers override lifecycle signals and duplicate-registration guards; previously flagged helper parameters are typed.
tests/test_litellm/litellm_core_utils/test_litellm_logging.py	The latest change annotates the fixture with the already-imported LitellmLogging class, resolving the remaining typing finding.

_{Reviews (3): Last reviewed commit: "fix(router): bind per-request routing_st..." | Re-trigger Greptile}

[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.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[devin-ai-integration]

@greptileai please re-review a933424: group-aware guard, typed test helpers, and the multi-worker live A/B are in this head.

[mateo-berri]

bugbot run

[cursor]

Stale Bugbot comment from a previous run.

[devin-ai-integration]

@greptileai

[mateo-berri]

bugbot run

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit f808c68. Configure here.}