[Fix] Failure callbacks silently skipped when customLogger not initialized#24826
[Fix] Failure callbacks silently skipped when customLogger not initialized#24826ishaan-berri merged 2 commits intomainfrom
Conversation
… fire The sync and async failure handlers guarded plain-function callbacks with `customLogger is not None`, but customLogger was only initialized in the success handler path. If a request failed without any prior success in the process, the failure callback was silently skipped. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
|
Greptile SummaryThis PR fixes a real bug where callable failure callbacks (both sync and async) were silently skipped whenever Key changes:
Remaining inconsistencies (not introduced by this PR):
Confidence Score: 4/5Safe to merge; the targeted fix is correct, but two analogous silent-skip sites remain unfixed in pre_call and the sync success handler The fix is correct and directly addresses the stated bug with the appropriate lazy-init pattern. Score is 4 rather than 5 because two peer code paths (pre_call at line 1077 and sync success at line 2421) retain the same customLogger is not None pattern that this PR was created to eliminate, leaving them susceptible to the same class of silent callback skipping. litellm/litellm_core_utils/litellm_logging.py — lines 1077 and 2421 still use the unfixed pattern
|
| Filename | Overview |
|---|---|
| litellm/litellm_core_utils/litellm_logging.py | Fixes silent skip of callable failure callbacks when customLogger is None; two analogous old-pattern sites remain at pre_call (line 1077) and sync success handler (line 2421) |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Request fails] --> B[failure_handler / async_failure_handler]
B --> C{Iterate callbacks}
C --> D{isinstance CustomLogger?}
D -- Yes --> E[callback.log_failure_event / async_log_failure_event]
D -- No --> F{callable callback?}
F -- No --> C
F -- Yes --> G{customLogger is None?}
G -- Yes BEFORE FIX --> H[❌ Silent skip]
G -- Yes AFTER FIX --> I[customLogger = CustomLogger]
I --> J[customLogger.log_event / async_log_event]
G -- No --> J
E --> C
J --> C
style H fill:#f44,color:#fff
style I fill:#4a4,color:#fff
style J fill:#4a4,color:#fff
Reviews (2): Last reviewed commit: "Merge remote-tracking branch 'origin/mai..." | Re-trigger Greptile
|
| GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
|---|---|---|---|---|---|
| 29375658 | Triggered | JSON Web Token | 3308fb9 | tests/test_litellm/proxy/auth/test_handle_jwt.py | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secret safely. Learn here the best practices.
- Revoke and rotate this secret.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
Summary
Failure Path (Before Fix)
The sync and async failure handlers in
litellm_logging.pyguarded plain-function callback dispatch withcustomLogger is not None. However,customLoggeris a module-level global initialized toNoneand only set to aCustomLogger()instance inside the success handler path. If a request failed without any prior successful request in the process,customLoggerstayedNoneand the failure callback (e.g. Router'sasync_deployment_callback_on_failurefor RPM tracking) was silently skipped.Fix
Initialize
customLoggeron demand in both the sync and async failure handlers, matching the pattern already used in the success handlers.Testing
test_call_router_callbacks_on_failurenow passes (was consistently failing in CI)test_call_router_callbacks_on_successcontinues to passType
🐛 Bug Fix