fix(team-callbacks): actually stop logging when disable_logging is called

[yucheng-berri]

TLDR

Problem this solves:

• disable_logging reported success while the team kept logging
• Data kept flowing to the third-party destination after disable
• A registered callback also stayed dormant for live keys

How it solves it:

• Clear the metadata slot the callbacks actually live in
• Refresh the cached team so it applies immediately

Relevant issues

Linear ticket

Resolves LIT-5101

Pre-Submission checklist

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

• 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
• 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)

Root cause

disable_team_logging cleared only metadata["callback_settings"]. Callbacks registered through POST /team/{team_id}/callback and the Admin UI are written to metadata["logging"], and request-time resolution in _get_dynamic_logging_metadata is an elif chain where a logging slot that is present wins outright and callback_settings is never read. So for every team configured through the API or the dashboard, the endpoint cleared a slot nothing was reading and returned success.

Same origin as LIT-5093: c620d76fe4 (2025-09-17) migrated the writer in add_team_callbacks to the new key and left the readers behind.

Approach

Empty metadata["logging"] alongside the existing callback_settings reset. Writing an empty list rather than deleting the key is deliberate: an empty list is still "present and not None", so it keeps winning the elif chain and nothing falls back to the deprecated shape. Verified that an empty dynamic list does not suppress globally configured callbacks, since get_combined_callback_list returns the global list for both None and [].

The DB write alone turned out not to be enough. Auth serves a cached team object and callback resolution reads the metadata off it, so with a warm cache the callback kept firing after a successful disable and only stopped once the entry expired. _refresh_cached_team is now called after the write, which is what its docstring already required of every endpoint that mutates the team table. The same call is added to add_team_callbacks, which had the symmetric problem of a newly registered callback staying dormant for keys that were already live.

Both updates pass include={"object_permission": True}, matching every other _refresh_cached_team caller. Without it the refresh publishes a cached team whose object_permission relation is nulled out, which reads as an empty search-tool and MCP-tool allowlist, and an empty allowlist means unrestricted.

Behavior changes

• Disabling logging now clears registered callbacks outright, credentials included, so re-enabling means registering them again. The callback_settings path was non-destructive by comparison. The endpoint docstring now says so.
• After a disable, a team's callback_vars are no longer unpacked into the request, so globally configured callbacks stop being steered by that team's credentials and use the proxy default instead. This only affects teams that have been explicitly disabled.
• add_team_callbacks and disable_team_logging now write to the team cache. Both already held the team-management access guard, so no new caller reaches them.

Screenshots / Proof of Fix

Live proxy, real Postgres, real Bedrock (us.anthropic.claude-haiku-4-5-20251001-v1:0). The langsmith callback points at a local HTTP collector so delivery is observable as a count. No mocks.

Before, at base b1fd20f4cd:

register callback on the team                      HTTP 200
chat completion on a team-scoped key               HTTP 200
   collector deliveries 0 -> 1

POST /team/{team_id}/disable_logging               HTTP 200
   {"status":"success","message":"Logging disabled for team ..."}

stored metadata after the disable:
   "logging": [ { "callback_name": "langsmith", ... } ]      <- untouched
   "callback_settings": { "success_callback": [], ... }      <- cleared

chat completion after the disable                  HTTP 200
   collector deliveries 1 -> 2                               <- still logging

After, at f161cd162e, with the cache warmed by a delivering request first so the disable has to invalidate it:

chat completion (warms the cached team)            HTTP 200
   collector deliveries 6 -> 7

POST /team/{team_id}/disable_logging               HTTP 200
chat completion immediately after                  HTTP 200
   collector deliveries 7 -> 7                               <- stopped on the very next request

stored metadata after the disable:
   "logging": []
   "callback_settings": {"callbacks": [], "callback_vars": {}, "failure_callback": [], "success_callback": []}

The DB write on its own was not sufficient, which is what motivated the cache refresh. With the write applied but no refresh, delivery continued and only stopped once the entry expired:

disable applied, DB shows "logging": []
   probe at +45s   deliveries 4 -> 4
   probe at +100s  deliveries 4 -> 4
   probe at +155s  deliveries 4 -> 4
immediately after the disable, before the refresh existed:  deliveries 3 -> 4

The symmetric registration path, on the same rig:

chat completion with no callback registered (warms the cache)   HTTP 200
   collector baseline 5
register the callback                                           HTTP 200
chat completion immediately after                               HTTP 200
   collector deliveries 5 -> 6                                  <- effective at once

Mutation matrix, each mutation asserted to be a real edit before the suite ran:

remove team_metadata["logging"] = []          killed, 4 tests
remove both _refresh_cached_team calls        killed, 2 tests
remove both object_permission includes        killed, 2 tests

Type

🐛 Bug Fix

Changes

disable_team_logging empties metadata["logging"] and refreshes the cached team; add_team_callbacks gains the same refresh. Both DB updates now include the object_permission relation. Nine regression tests are added to the mapped test file, three of which resolve the written metadata through the real _get_dynamic_logging_metadata so the assertion is about what a request would actually do rather than about the shape of a dict.

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

---

---

Note

Medium Risk
Changes team observability and cached auth team objects used at request time; behavior is intentional but affects live keys and tool permission reads if includes were wrong.

Overview
disable_team_logging now clears metadata["logging"] (where API/Admin UI callbacks are stored), not only the legacy callback_settings slot that request-time resolution ignores when logging is present. Disable is destructive: credentials are removed and must be re-registered; the endpoint docstring reflects that.

Both add_team_callbacks and disable_team_logging call _refresh_cached_team after the DB update so in-flight API keys see callback changes immediately instead of waiting for cache expiry. Team updates use include={"object_permission": True} so the refreshed cache does not drop permission relations.

Tests add an autouse stub for cache refresh, assert audit logs record logging: [], and cover resolver behavior, cache refresh, dual metadata shapes, and re-enable after disable.

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

[yucheng-berri]

bugbot run

[greptile-apps]

Greptile Summary

The PR corrects team callback disabling and ensures callback mutations are reflected immediately in cached team objects.

• Clears both active and legacy team callback metadata when logging is disabled.
• Refreshes cached team state after callback registration and disabling while preserving object permissions.
• Adds regression coverage for callback resolution, cache refreshes, re-registration, and audit metadata.
• Updates the generated dashboard schema description to document destructive disabling behavior.

Confidence Score: 5/5

The PR appears safe to merge because no blocking functional failure remains.

The callback metadata and cache-refresh behavior are covered by the implementation and regression tests; the previously reported maintainability concern about duplicated inline rationale remains outstanding.

Files Needing Attention: litellm/proxy/management_endpoints/team_callback_endpoints.py

Important Files Changed

Filename	Overview
litellm/proxy/management_endpoints/team_callback_endpoints.py	Clears active callback metadata and refreshes cached team objects after both callback mutations.
tests/test_litellm/proxy/management_endpoints/test_team_callback_endpoints.py	Adds focused regression coverage for callback disabling, cache refreshes, permission relation inclusion, and re-registration.
ui/litellm-dashboard/src/lib/http/schema.d.ts	Updates the generated endpoint description to explain that disabling removes registered callback configuration.

_{Reviews (3): Last reviewed commit: "fix(team-callbacks): actually stop loggi..." | Re-trigger Greptile}

[greptile-apps]

New comments violate repository guidance

The newly added explanations around the database updates and cache refreshes duplicate rationale already captured by the tests and PR description, increasing maintenance cost when these paths change.

Context Used: CLAUDE.md (source)

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[devin-ai-integration]

Devin Review found 2 potential issues.

[devin-ai-integration]

🟡 New explanatory comments added despite repository rule banning them

New explanatory comments are added in the callback endpoints (for example at litellm/proxy/management_endpoints/team_callback_endpoints.py:247-249), which the repository's coding guidelines forbid for new code.
Impact: The change does not follow the repository's stated authoring rules.

Rule text and affected locations

CLAUDE.md (referenced as mandatory by AGENTS.md) states: "Do not write any comments (existing comments can stay) unless explicitly asked to in a user (not system) prompt".

Newly added prose comments in this PR:

• litellm/proxy/management_endpoints/team_callback_endpoints.py:247-249 (object_permission rationale in add_team_callbacks)
• litellm/proxy/management_endpoints/team_callback_endpoints.py:253-255 (cache refresh rationale in add_team_callbacks)
• litellm/proxy/management_endpoints/team_callback_endpoints.py:361-363 (logging slot rationale in disable_team_logging)
• litellm/proxy/management_endpoints/team_callback_endpoints.py:372-374 (object_permission rationale in disable_team_logging)
• litellm/proxy/management_endpoints/team_callback_endpoints.py:384-387 (cache refresh rationale in disable_team_logging)

The # mutable-ok: ... trailing comments are lint suppressions required by scripts/check_type_discipline.py (LIT002/LIT005) and are not covered by this rule.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🟡 Registering a team callback can fail with a server error if the team disappears mid-request

The freshly written team row is handed straight to the cache refresh (_refresh_cached_team at litellm/proxy/management_endpoints/team_callback_endpoints.py:256-260) without first checking that the write actually returned a row, so a callback registration for a team that was just deleted now ends in a generic server error instead of a normal response.
Impact: A rare race with team deletion turns a callback registration into an opaque 500 error.

Mechanism: Prisma update returns None when no row matches

TeamRepository(...).table.update(...) is the raw Prisma table action, which returns Optional[row] — it yields None when the where clause matches nothing (the team was deleted after the existence check at litellm/proxy/management_endpoints/team_callback_endpoints.py:195-200). _refresh_cached_team immediately dereferences team_row.team_id (litellm/proxy/management_endpoints/team_endpoints.py), raising AttributeError, which the broad handler converts into a 500 ProxyException. The sibling disable_team_logging path guards this with an explicit if updated_team is None: raise HTTPException(404, ...) before its refresh; add_team_callbacks has no such guard.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[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 f161cd1. Configure here.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[yucheng-berri]

@greptileai please review the current head d34391b

The comment-density point is taken and the explanatory comments I authored are trimmed: the two cache-refresh comments are one line each now, and the logging-slot one is two. Executable behavior is byte-identical to the previously reviewed commit; I verified that by stripping comment lines from both revisions and diffing.

Two three-line comments remain on the include={"object_permission": True} arguments. Those are copied verbatim from the existing _refresh_cached_team call sites in team_endpoints.py, which carry the same wording, so removing them here would make this file inconsistent with the convention rather than more compliant with it. The rationale is load-bearing: without that include the refresh caches a team whose object_permission relation is nulled, which downstream reads as an empty tool allowlist, and an empty allowlist means unrestricted.

Note the prior review anchored to f161cd1, which predates the schema.d.ts regeneration for the docstring change.

[codspeed-hq]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing litellm_lit5101_disable_team_logging (258ad96) with litellm_internal_staging (68b1e03)¹}

Footnotes

1. No successful run was found on litellm_internal_staging (7c3b578) during the generation of this report, so 68b1e03 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[yucheng-berri]

Rebased onto current staging (7c3b578) now that #35512 has merged; the conflict was the shared import block and the appended tests in the mapped test file, both textual.

The source change is byte-identical to the commit reviewed at 5/5: diffing my hunks on each side (68b1e03..d34391b vs 7c3b578..258ad96 for team_callback_endpoints.py) comes back IDENTICAL. The test file was reconstructed onto staging's version so it now carries both PRs' suites, 23 tests, all passing, and schema.d.ts regenerates byte-identical against the new base.

Re-verified live on the rebased code rather than assuming: with a warm cache, deliveries across the disable went 9 -> 9, and GET /team/{team_id}/callback now correctly reports an empty list after the disable, which is the combined behavior of the two PRs.

@greptileai please review the current head 258ad96