mirror of
https://github.com/BerriAI/litellm.git
synced 2026-09-19 00:01:29 +00:00
4c18f557b1
partition_spend_logs.sql and unpartition_spend_logs.sql hardcode every
index Prisma defines on LiteLLM_SpendLogs, because `LIKE ... INCLUDING
DEFAULTS INCLUDING GENERATED` copies columns but not indexes. They also
rename the old table's indexes aside first, since index names are unique
per schema and a surviving name makes `CREATE INDEX IF NOT EXISTS` a
silent no-op.
The new (api_key, startTime) index was in neither list, so an operator who
partitions (or unpartitions) after this migration lands gets a replacement
table without it, and Prisma will not recreate it: the migration is already
recorded as applied, and `migrate deploy` skips its drift sanity check when
there is nothing pending.
Verified on Postgres 18 against the shipped migration statements:
* unpatched partition script -> parent table has no api_key index, and
re-running the migration's own `CREATE INDEX IF NOT EXISTS` reports
success while being skipped, because the legacy table still owns the
name. The recovery an operator would reach for silently does nothing.
* patched -> index survives partitioning, propagates to every partition
(LiteLLM_SpendLogs_p*_api_key_startTime_idx) and to DEFAULT, is chosen
by the planner for the key+date-range query shape the endpoints use,
and survives the unpartition round-trip with all rows intact.
|
||
|---|---|---|
| .. | ||
| backfill_daily_tool_spend.sql | ||
| create_views.py | ||
| migrate_keys.py | ||
| partition_spend_logs.sql | ||
| unpartition_spend_logs.sql | ||
| update_unassigned_teams.py | ||