[Bug]: Startup schema check suggests an invalid primary-key rewrite for partitioned SpendLogs #45988

Description

With LiteLLM_SpendLogs partitioned by "startTime", the proxy's startup schema check reports an out-of-sync schema and recommends replacing the required composite primary key with a primary key on request_id alone

This was observed in two running environments with completed migrations and working spend-log writes. A fresh read-only Prisma diff against each deployed schema contains only this primary-key rewrite. No application indexes were invalid or unready, and there were no unfinished, unrolled-back entries in _prisma_migrations. The warning persists after removing the expired LiteLLM_SpendLogs_legacy table

The partitioned parent has relkind = 'p' and these definitions

RANGE ("startTime")
PRIMARY KEY (request_id, "startTime")

The startup diagnostic reports

prisma schema out of sync with db. Consider running these sql_commands to sync the two

The SQL below is the observed diagnostic output, and would be invalid for this partitioned layout because the primary key must include the partition key

ALTER TABLE "LiteLLM_SpendLogs" DROP CONSTRAINT "LiteLLM_SpendLogs_pkey",
ADD CONSTRAINT "LiteLLM_SpendLogs_pkey" PRIMARY KEY ("request_id");

Config

Relevant excerpt, with the connection string supplied through the environment

general_settings:
  database_url: os.environ/DATABASE_URL
  use_spend_logs_partitioning: true
  maximum_spend_logs_retention_period: "30d"

LiteLLM Version

Observed in a downstream deployment based on LiteLLM 1.106.0, using PostgreSQL 16

The relevant startup-check behavior was also verified by source inspection in upstream main at commit 102619d47a78d80f0383c9e8f52446046f0ecc6b. I have not run an isolated reproduction using an unmodified upstream image

Steps to Repro

On a disposable PostgreSQL database, initialize the LiteLLM schema, enable spend-log partitioning, and apply the supported layout from db_scripts/partition_spend_logs.sql

Restart the proxy with the normal migration and startup checks, then inspect the schema warning. The underlying read-only comparison can also be run directly from the directory containing the deployed schema.prisma

prisma migrate diff \
  --from-url "$DATABASE_URL" \
  --to-schema-datamodel ./schema.prisma \
  --script

Confirm the live layout with

SELECT pg_get_partkeydef('public."LiteLLM_SpendLogs"'::regclass);

SELECT pg_get_constraintdef(oid)
FROM pg_constraint
WHERE conrelid = 'public."LiteLLM_SpendLogs"'::regclass
  AND contype = 'p';

Expected behavior

The startup diagnostic should recognize the supported partitioned SpendLogs layout and omit the incompatible primary-key rewrite. Genuine drift on other tables, columns, indexes, or constraints should still be reported, including primary-key drift when SpendLogs is an ordinary table

Relevant code

check_prisma_schema_diff_helper prints and returns the raw Prisma diff, which check_prisma_schema_diff then logs as an out-of-sync schema

There is already a filter_partitioned_spend_logs_diff used by _filter_migration_job_owned_drift. The startup diagnostic path does not reuse that partition-aware filtering

A possible fix is to detect the live partitioned parent and apply the existing filter before printing or logging the diagnostic

Related to #40119, which tracks partitioned SpendLogs migration failures. This report focuses on the startup diagnostic and unsafe SQL recommendation while migrations are complete and the proxy is running successfully

Which part of LiteLLM is this about?

Database: Prisma, migrations, Postgres

How are you deploying?

Docker on Kubernetes