fix: add hook to handle db case

[Harshit28j]

Verified the fix: with the database stopped, requests fail with 401 and connection errors.
These failures are now visible in Datadog Logs, matching the behavior we wanted after the incident where Datadog showed no sign of the outage.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
litellm	Ready	Preview, Comment	Feb 7, 2026 5:06am

[greptile-apps]

Greptile Overview

Greptile Summary

Added async_post_call_failure_hook to the DataDog logger to capture proxy-level failures (e.g., 401 authentication errors, database connection errors) that occur before or outside the LLM completion flow. This ensures these failures are visible in Datadog logs alongside Prometheus metrics.

Key Changes:

• Implemented new hook method that extracts error information, sanitizes user context, and logs to Datadog with ERROR status
• Uses existing utilities (StandardLoggingPayloadSetup.get_error_information, LiteLLMProxyRequestSetup.get_sanitized_user_information_from_key) without creating new database requests
• Includes fallback logic for SDK-only usage when proxy utilities aren't available
• Follows batching pattern consistent with other logging methods (appends to queue, sends when batch size reached)
• Changed wildcard import to explicit imports for better code clarity
• Minor formatting improvements (whitespace cleanup)

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• The implementation follows established patterns in the codebase, uses existing utility functions without creating new database requests (complying with custom rule 0c2a17ad), properly handles exceptions, includes fallback logic, and addresses the specific issue described in the PR (making DB outage failures visible in Datadog logs).
• No files require special attention

Important Files Changed

Filename	Overview
litellm/integrations/datadog/datadog.py	Added async_post_call_failure_hook to log proxy-level failures (401 auth, DB connection errors) to Datadog, ensuring visibility of failures that occur before LLM completion flow. Also changed wildcard import to explicit imports for better clarity.

Sequence Diagram

sequenceDiagram
    participant Client
    participant ProxyUtils as Proxy Utils
    participant DataDogLogger as DataDog Logger
    participant DataDogAPI as DataDog API

    Client->>ProxyUtils: Request (e.g., auth fails or DB down)
    ProxyUtils->>ProxyUtils: Exception occurs (401 or ConnectError)
    ProxyUtils->>DataDogLogger: async_post_call_failure_hook(request_data, exception, user_api_key_dict)
    
    DataDogLogger->>DataDogLogger: Extract error info (status_code, error_class, traceback)
    
    alt Proxy Available
        DataDogLogger->>DataDogLogger: get_sanitized_user_information_from_key(user_api_key_dict)
        Note over DataDogLogger: Extracts user context (team_id, user_id, etc.)
    else Proxy Not Available
        DataDogLogger->>DataDogLogger: Fallback to hasattr checks
        Note over DataDogLogger: Minimal safe fields extraction
    end
    
    DataDogLogger->>DataDogLogger: Create DatadogProxyFailureHookJsonMessage
    DataDogLogger->>DataDogLogger: Create DatadogPayload with ERROR status
    DataDogLogger->>DataDogLogger: Add trace context if available
    DataDogLogger->>DataDogLogger: Append to log_queue
    
    alt Queue >= batch_size
        DataDogLogger->>DataDogAPI: async_send_batch()
        DataDogAPI-->>DataDogLogger: 202 Accepted
    else Queue < batch_size
        Note over DataDogLogger: Wait for periodic flush (5s) or next batch
    end
    
    ProxyUtils-->>Client: Return error response

Loading

[greptile-apps]

_{1 file reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}