fix: make db migration failure exit opt-in via --enforce_prisma_migration_check

[ghost]

Summary

• Database migration failures now warn and continue by default instead of calling sys.exit(1).
• Added --enforce_prisma_migration_check CLI flag (or ENFORCE_PRISMA_MIGRATION_CHECK=true env var) to opt into exiting on migration failure.
• Fixed two pre-existing pyright errors: reportArgumentType on get_secret return type and reportPossiblyUnboundVariable on litellm_settings.

Pre-Submission checklist

• I have Added testing in the tests/test_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

Type

🐛 Bug Fix

Changes

• Replaced --skip_db_migration_check with --enforce_prisma_migration_check in proxy_cli.py
• Default: warn and continue on db migration failure
• Opt-in: set --enforce_prisma_migration_check to exit on failure

🤖 Generated with Claude Code

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
litellm	Ready	Preview, Comment	Mar 15, 2026 1:56am

[greptile-apps]

Greptile Summary

This PR renames the --skip_db_migration_check CLI flag to --enforce_prisma_migration_check and fixes a misleading error message that told users to pass a flag they had already passed. It also fixes two pre-existing pyright errors: a type coercion on the get_secret return value and an unbound litellm_settings variable.

Key issues:

• Breaking default behavior change: The most critical problem is that the default behavior has been silently inverted. Previously, sys.exit(1) was the default (safe) outcome when DB setup failed; passing --skip_db_migration_check was the opt-in to continue with a warning. After this PR, the default is now "warn and continue" — meaning every deployment that omitted the flag (the majority of users) will now no longer have the proxy exit on DB failure. This is a backwards-incompatible regression that violates the project's policy of not changing default behavior without a feature flag.
• Dropped env var / CLI flag without deprecation: SKIP_DB_MIGRATION_CHECK and --skip_db_migration_check are silently removed. Operators with these flags in Dockerfiles, Helm values, or startup scripts will get the new permissive default instead of their intended opt-in, with no error or deprecation warning.
• PR description does not match actual changes: The description says "when database setup fails, the proxy exits with sys.exit(1) by default" and mentions --skip_db_migration_check throughout, but the code has replaced that flag and changed the default to the opposite behavior.
• No tests added: The pre-submission checklist's testing item remains unchecked; the new code path (warn and continue as default) and the strict-exit opt-in path lack unit-test coverage.

Confidence Score: 1/5

• Not safe to merge — the default behavior change silently makes DB-failure handling permissive for all existing deployments that omit the flag.
• The core intent of the PR (fixing a confusing error message) is sound, but the implementation inverts the default behavior from "exit on failure" to "warn and continue". This is a backwards-incompatible change that could cause production deployments to silently start without a database. The old flag and env var are also dropped without a deprecation path.
• litellm/proxy/proxy_cli.py — specifically lines 559–565 (flag definition) and 868–881 (the branching logic that changed the default).

Important Files Changed

Filename	Overview
litellm/proxy/proxy_cli.py	Renames --skip_db_migration_check to --enforce_prisma_migration_check and inverts the default behavior from "exit on failure" to "warn and continue", introducing a backwards-incompatible behavioral change. Also fixes a pyright type error with str(database_url) and initializes litellm_settings = None to prevent an unbound variable warning.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Proxy startup] --> B{DATABASE_URL set and prisma found?}
    B -- No --> C[Print warning: prisma not found]
    B -- Yes --> D{should_update_prisma_schema?}
    D -- False --> E[check_prisma_schema_diff]
    D -- True --> F[PrismaManager.setup_database]
    F --> G{Setup succeeded?}
    G -- Yes --> H[Continue startup]
    G -- No --> I{enforce_prisma_migration_check set?}
    I -- True opt-in --> J[Print error and sys.exit 1]
    I -- False default --> K[Print warning and continue startup]

    subgraph NEW[NEW default after this PR]
        K
    end

    subgraph OLD[OLD default before this PR]
        OB[Print error and sys.exit 1 was the default]
    end

    style J fill:#ff4444,color:#fff
    style K fill:#ffcc00,color:#000
    style OB fill:#ff4444,color:#fff

Loading

_{Last reviewed commit: a53ecd5}

[greptile-apps]

str() coercion may silently corrupt URL

get_secret has no explicit return type annotation; pyright infers it can return str | bool | None. The guard str(database_url) if database_url else None resolves the type error, but if the secrets manager ever returns bytes (e.g. from an AWS Secrets Manager binary secret), str(b"postgresql://...") produces the literal string "b'postgresql://...'", which is an invalid URL that would silently be set as DATABASE_URL and break the DB connection.

A safer fix that also satisfies the type checker would be:

database_url = get_secret("DATABASE_URL", default_value=None)
if isinstance(database_url, bytes):
    database_url = database_url.decode("utf-8")
modified_url = append_query_params(
    database_url if isinstance(database_url, str) else None, params
)

This is a low-probability edge case, but worth guarding against explicitly since DATABASE_URL is security-critical.

[greptile-apps]

Missing test for the new error path

The PR description's own pre-submission checklist notes "Adding at least 1 test is a hard requirement," but the tests checkbox is unchecked and no test was added. The new sys.exit(1) code path (when skip_db_migration_check is False and setup fails) and the updated warning branch (when skip_db_migration_check is True) both lack unit-test coverage. Without tests, a future refactor could silently regress the corrected message or remove the sys.exit(1) call.

Consider adding tests in tests/test_litellm/ that mock PrismaManager.setup_database to return False and assert:

1. The correct exit message is printed and sys.exit(1) is called when skip_db_migration_check=False.
2. The correct warning message is printed and startup continues when skip_db_migration_check=True.

Rule Used: What: Ensure that any PR claiming to fix an issue ... (source)

[codspeed-hq]

Merging this PR will not alter performance

✅ 16 untouched benchmarks

---

_{Comparing krrishdholakia/db-exit-opt-in (a53ecd5) with main (be20a8a)}

[greptile-apps]

Default behavior inverted — backwards-incompatible change

The PR inverts the default behavior in a backwards-incompatible way, violating the project's policy of never making breaking changes without a user-controlled feature flag.

Before (original code):

• Default (skip_db_migration_check=False): sys.exit(1) on DB failure — safe/strict by default
• Opt-in (--skip_db_migration_check): warn and continue — permissive, explicit user choice

After (this PR):

• Default (enforce_prisma_migration_check=False): warn and continue — permissive by default
• Opt-in (--enforce_prisma_migration_check): sys.exit(1) on DB failure

This means any production deployment that previously relied on the proxy stopping when the database was unreachable will now silently start up and attempt to serve requests without a database. This is a regression: operators who deployed without --skip_db_migration_check intentionally wanted the strict behavior.

Additionally, the old env var SKIP_DB_MIGRATION_CHECK and CLI flag --skip_db_migration_check are silently dropped. Any Dockerfiles, Helm charts, or startup scripts referencing those flags will now be ignored without error, and those deployments will get the new (permissive) default rather than the intended (permissive) opt-in they explicitly configured.

To fix this without breaking existing deployments, the original semantics should be preserved: keep sys.exit(1) as the default and fix only the misleading message. The message fix from this PR is correct and should be kept:

if skip_db_migration_check:
    print(  # noqa
        "\033[1;33mLiteLLM Proxy: Database migration failed but continuing startup. "
        "Set SKIP_DB_MIGRATION_CHECK=true to suppress this warning.\033[0m"
    )
else:
    print(  # noqa
        "\033[1;31mLiteLLM Proxy: Database setup failed after multiple retries. "
        "The proxy cannot start safely. Pass --skip_db_migration_check or set "
        "SKIP_DB_MIGRATION_CHECK=true to warn and continue instead of exiting.\033[0m"
    )
    sys.exit(1)

Rule Used: What: avoid backwards-incompatible changes without... (source)

[ghost]

This is an intentional change. We do not want to block on startup, as the initial PR added this week caused that regression. We want to make strict enforcement opt in for now, and move to it being default, with time.