[Fix] /user/update Allow for max_budget Resets

[yuneng-jiang]

Relevant issues

Pre-Submission checklist

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

• I have Added testing in the tests/litellm/ directory, Adding at least 1 test is a hard requirement - see details
• My PR passes all unit tests on make test-unit
• My PR's scope is as isolated as possible, it only solves 1 specific problem

CI (LiteLLM team)

CI status guideline:

• 50-55 passing tests: main is stable with minor issues.
• 45-49 passing tests: acceptable but needs attention
• <= 40 passing tests: unstable; be careful with your merges and assess the risk.

• Branch creation CI run
  Link:

• CI run for the last commit
  Link:

• Merge / cherry-pick CI run
  Links:

Type

🐛 Bug Fix
✅ Test

Changes

Fixes an issue where max_budget could not be reset because _update_internal_user_params always included it in non_default_values even when not provided in the request. The function now checks if max_budget is explicitly set using fields_set() before including it, allowing it to be reset when provided while preserving the original value when omitted.

Screenshots

BEFORE:

AFTER:

TESTS:

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
litellm	Ready	Preview, Comment	Feb 4, 2026 0:34am

[greptile-apps]

Greptile Overview

Greptile Summary

Fixed a bug where max_budget could not be preserved when updating a user without explicitly providing it in the request. The issue was in _update_internal_user_params() which previously always included max_budget in update values if present in data_json, even when it wasn't explicitly set by the caller.

Key Changes:

• Added fields_set() check in _update_internal_user_params() to verify if max_budget was explicitly provided
• max_budget now only included in updates when it appears in the model's fields_set(), allowing the database to preserve existing values when not provided
• Added comprehensive test test_update_internal_user_params_keeps_original_max_budget_when_not_provided() to verify the fix

Technical Details:
The fix leverages Pydantic's fields_set() method (which works across both Pydantic v1 and v2 via the LiteLLMPydanticObjectBase.fields_set() wrapper) to distinguish between "field not provided" and "field explicitly set to a value (including None)". This allows:

• Resetting max_budget to None when explicitly provided
• Updating max_budget to a new value when provided
• Preserving the existing database value when omitted from the request

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• The fix is well-designed, properly tested, and follows best practices. It uses Pydantic's built-in fields_set() mechanism to accurately determine which fields were explicitly provided, which is the correct approach for this type of partial update scenario
• No files require special attention

Important Files Changed

Filename	Overview
litellm/proxy/management_endpoints/internal_user_endpoints.py	Fixed max_budget reset logic by checking fields_set() to determine if explicitly provided
tests/test_litellm/proxy/management_endpoints/test_internal_user_endpoints.py	Added comprehensive test for max_budget preservation when not provided in request

Sequence Diagram

sequenceDiagram
    participant Client
    participant UpdateEndpoint
    participant UpdateHelper
    participant UpdateParser
    participant Database

    Client->>UpdateEndpoint: POST /user/update with partial fields
    UpdateEndpoint->>UpdateHelper: Process UpdateUserRequest
    UpdateHelper->>UpdateHelper: Create data_json via model_dump
    Note over UpdateHelper: Only includes explicitly provided fields
    UpdateHelper->>UpdateParser: Call _update_internal_user_params
    UpdateParser->>UpdateParser: Get fields_set from request model
    alt max_budget in request
        UpdateParser->>UpdateParser: Include max_budget in updates
    else max_budget NOT in request
        UpdateParser->>UpdateParser: Skip max_budget (preserve existing)
    end
    UpdateParser-->>UpdateHelper: Return filtered update values
    UpdateHelper->>Database: Update user with filtered values
    Database-->>UpdateHelper: Return updated user
    UpdateHelper-->>UpdateEndpoint: Success response
    UpdateEndpoint-->>Client: 200 OK

Loading

[greptile-apps]

_{2 files reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}