6 views
-/https://github.com/berriai/litellm/issues/33074
GitHub · issue

#33074 [Bug]: LiteLLM v1.92 budget_fallbacks issue

  • State: open
  • Author: @jpaodev
  • Labels: bug

### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### What happened?

After updating to version v1.92 I ran into a critical issue with a missing `budget_fallbacks` column, which caused fatal issues (no login to Admin UI possible, no API usage possible)

``` litellm 14:19:38 - LiteLLM Proxy:ERROR: utils.py:5783 - Exception: The column `LiteLLM_VerificationToken.budget_fallbacks` does not exist in the current database. litellm prisma.errors.DataError: The column `LiteLLM_VerificationToken.budget_fallbacks` does not exist in the current database. ```

I assume this migration must have failed? https://github.com/BerriAI/litellm/pull/31783/changes#diff-dea8462b04204dbc34dcf13d9a4591a617cdfbf74055482d035e94aeadd1319a

### Steps to Reproduce

1. Upgrade to latest LiteLLM version (as of writing 1.92) 2. Wait 3. Test requests against liteLLM with a key

### Relevant log output

```shell

```

### What part of LiteLLM is this about?

_No response_

### What LiteLLM version are you on ?

1.91.3 (after rollback)

### Twitter / LinkedIn details

_No response_

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (7 events)
#0 of 0 · 31d18h57m15s ago — entered · #import:https:::github.com:berriai:litellm post #1906
The left issue is harder because it involves database schema migration reliability, upgrade-path compatibility, failure recovery, and validation across deployments. The right issue is comparatively localized logic with a narrower behavioral change and focused tests.
33074 has higher implementation risk because it involves database schema migration compatibility, upgrade-state handling, and deployment recovery across existing installations; 26443 is comparatively localized to provider classification and request-parameter transformation logic.
Cross-provider protocol translation requires tracing message normalization across endpoints and model adapters, with careful preservation of tool-call ordering and broad regression coverage. The other issue is comparatively localized to database schema migration and version compatibility.
The right-hand task is harder because it requires diagnosing and safely repairing schema-migration behavior across existing deployments, with compatibility and data-integrity risk. The left-hand task is comparatively contained to SDK contract updates, request handling, and focused tests.
The right issue is harder because it requires diagnosing and safely correcting a production database schema migration across upgrade paths, with compatibility testing and high operational risk; the left issue is a localized pricing-metadata update.
33074 is harder because it requires diagnosing and safely correcting database schema migration behavior across upgrade paths, ORM state, and existing deployments, with high operational risk. 33030 is comparatively localized to authorization matching logic with focused regression tests.
#0 of 0 · 31d17h54m54s ago — current · #import:https:::github.com:berriai:litellm post #2941
The left task has greater security risk and cross-cutting scope: it requires robust destination validation, consistent enforcement across request paths, bypass-resistant testing, and careful compatibility review. The right task is more localized to migration handling, schema/version compatibility, and upgrade recovery.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search