fix(proxy): unregister logging callbacks removed from the stored config

[yuneng-berri]

TLDR

Problem this solves:

• On rc/1.103.0, deleting a logging callback reports success but it keeps exporting
• The deleted callback stays listed in the Admin UI's callback list

How it solves it:

• Backport of fix(proxy): unregister logging callbacks removed from the stored config #43428 from main, one commit, same source and test changes
• Each config sync unregisters callbacks it registered that the stored config dropped
• Callbacks from the YAML file or code are never touched

User Flow

Before: an admin deletes a logging callback, gets a success message, and the proxy keeps exporting to it

1. They add langfuse_otel with POST http://localhost:4000/config/update and traffic starts reaching Langfuse
2. They delete it with POST http://localhost:4000/config/callback/delete and get Successfully deleted callback: langfuse_otel
3. GET http://localhost:4000/get/config/callbacks keeps listing langfuse_otel on every worker
4. New chat completions keep exporting to Langfuse

After: the delete sticks on every worker

1. They add langfuse_otel with POST http://localhost:4000/config/update and traffic starts reaching Langfuse
2. They delete it with POST http://localhost:4000/config/callback/delete and get Successfully deleted callback: langfuse_otel
3. GET http://localhost:4000/get/config/callbacks returns an empty list on every worker within 30 seconds
4. New chat completions export nothing, and adding the callback back makes exports resume

Relevant issues

Backport of #43428

Affected release

The read-only listing appears since v1.102.0-rc.1 (#38974). The leftover exports are older and also happen on v1.101.0

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/unit/<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)

The source and test additions are line for line the same as #43428, both commits included. The only cherry-pick conflict was test file placement: the anchor test on main does not exist on rc, so the new tests sit at the same spot without it. On this branch the new tests fail with the source change reverted (8 failed) and pass with it, and test_proxy_server.py, test_proxy_config.py and test_delete_callbacks_endpoint.py pass (724 tests)

Screenshots / Proof of Fix

Proxy started with --num_workers 2, a local Postgres, STORE_MODEL_IN_DB=True, a mock_response model named mock-gpt, and LANGFUSE_OTEL_HOST pointing at a local OTLP capture server that counts export POSTs. No real provider calls are needed since the bug is in callback registration, not the LLM call. "OTLP exports" counts export batches the capture server received

Before (cc111d1)

1. curl -s localhost:4000/config/update -H "Authorization: Bearer $LITELLM_MASTER_KEY" -H "Content-Type: application/json" -d '{"litellm_settings":{"success_callback":["langfuse_otel"]}}' returns {"message":"Config updated successfully"}, and 6 chats produce 1 export batch
2. curl -s localhost:4000/config/callback/delete -H "Authorization: Bearer $LITELLM_MASTER_KEY" -H "Content-Type: application/json" -d '{"callback_name":"langfuse_otel"}' returns {"message":"Successfully deleted callback: langfuse_otel","removed_callback":"langfuse_otel","remaining_callbacks":[],...}
3. curl -s localhost:4000/get/config/callbacks -H "Authorization: Bearer $LITELLM_MASTER_KEY" still returns [{"name": "langfuse_otel", ..., "type": "success"}]
4. After waiting 35 seconds for every worker's periodic sync, 10 chats produce 2 export batches, and 4 more /get/config/callbacks calls across workers all return ["langfuse_otel"]

After (8823a69)

1. Same /config/update call returns {"message":"Config updated successfully"}, and 6 chats produce 1 export batch
2. Same /config/callback/delete call returns the same success message
3. /get/config/callbacks returns []
4. After waiting 35 seconds, 10 chats produce 0 export batches, and 4 more /get/config/callbacks calls across workers all return []
5. Re-adding with the same /config/update call, then waiting 35 seconds, 10 chats produce 2 export batches

Type

🐛 Bug Fix

Caveats (if any)

Medium

• A callback listed in both the YAML file and the DB survives a DB delete
  • The YAML registered it first, so the sync never owned it
• Other workers drop a deleted callback on their next sync, up to 30 seconds later
• A DB-added callback is now unregistered when the YAML file starts setting the same key
  • YAML wins that key, so a restart already dropped it before this PR
• fix(proxy): unregister logging callbacks removed from the stored config #43428 has not merged on main yet, so its CI and review results still apply here

Low

• Non-string entries in the stored callback lists are now ignored instead of registered

[greptile-apps]

Confidence Score: 4/5

[Medium risk] Fixes callback cleanup when database config updates.

The PR should not merge until deleting a DB callback is shown to preserve the same callback when it was registered by code.

Findings

1.  Code callback loses ownership ▶

Summary

The PR tracks callbacks added during DB config synchronization and unregisters them when the resolved config drops their keys. It also preserves callbacks when config loading fails and adds removal and ownership tests.

_{Reviews (1) · Last reviewed commit: "fix(proxy): unregister logging callbacks..."}

[greptile-apps]

Code callback loses ownership

If code already registered "langfuse_otel" as a success callback, registering the same callback from the DB replaces that string with a logger instance. This snapshot records the instance as DB-owned. When an admin deletes the DB entry, the new removal logic deletes the instance, so the code-configured callback stops running too.

[yuneng-berri]

Valid, reproduced it. Fixed in #43434 for rc and on #43428 for main: the sync records replaced entries and restores them on delete