firestore.indexes.json has drifted from the live database and now duplicates two of its indexes #33

New Issue

2026-08-23T02:37:34-04:00

logan commented

2026-08-23 02:37:34 -04:00

firebase deploy --only firestore:indexes on 2026-08-23 reported four composite indexes that exist in the live c2-server database but are absent from infra/firestore/firestore.indexes.json, and offered to delete them (declined — they back live queries):

(calls)        system_id ASC,    ended_at ASC
(calls)        status ASC,       ended_at ASC
(calls)        org_id ASC,       started_at DESC
(alert_events) acknowledged ASC, triggered_at DESC

The file is therefore not a description of the database. Two consequences:

1. Duplicated indexes. The file declares calls (org_id ASC, started_at ASC) while the live database already had calls (org_id ASC, started_at DESC). Both now exist. Firestore reverse-scans an index, so the DESC one already served orderBy("started_at","desc") — and every query in lib/useCalls.ts and lib/useIncidents.ts is desc. The ASC copy is redundant storage plus extra write amplification on every call document, forever. Same story for alert_events.

2. Nothing checks the drift. Deploying is a manual step run by hand from WSL (server-26#13), so the file is only compared against reality when someone happens to run it. That is how it got four indexes behind without anyone noticing.

Worth doing:

Reconcile the file against gcloud firestore indexes composite list --database=c2-server --project=discord-radio-bot-461301 — adopt the live DESC variants, drop the ASC duplicates, and add the two calls indexes that are plainly in use (system_id+ended_at, status+ended_at, most likely the node sweeper and stale-call paths in c2-core).
Delete the redundant ASC copies once nothing references them.
Longer term, whatever automates server-26#13 should fail loudly on drift instead of prompting interactively.

Note for anyone running the deploy: infra/firestore/firebase.json now pins "database": "c2-server". Without that key the CLI targets (default), reports success, and changes nothing the app can see.

`firebase deploy --only firestore:indexes` on 2026-08-23 reported four composite indexes that exist in the live `c2-server` database but are absent from `infra/firestore/firestore.indexes.json`, and offered to delete them (declined — they back live queries): ``` (calls) system_id ASC, ended_at ASC (calls) status ASC, ended_at ASC (calls) org_id ASC, started_at DESC (alert_events) acknowledged ASC, triggered_at DESC ``` The file is therefore not a description of the database. Two consequences: **1. Duplicated indexes.** The file declares `calls (org_id ASC, started_at ASC)` while the live database already had `calls (org_id ASC, started_at DESC)`. Both now exist. Firestore reverse-scans an index, so the DESC one already served `orderBy("started_at","desc")` — and every query in `lib/useCalls.ts` and `lib/useIncidents.ts` is `desc`. The ASC copy is redundant storage plus extra write amplification on every call document, forever. Same story for `alert_events`. **2. Nothing checks the drift.** Deploying is a manual step run by hand from WSL (server-26#13), so the file is only compared against reality when someone happens to run it. That is how it got four indexes behind without anyone noticing. Worth doing: - Reconcile the file against `gcloud firestore indexes composite list --database=c2-server --project=discord-radio-bot-461301` — adopt the live DESC variants, drop the ASC duplicates, and add the two `calls` indexes that are plainly in use (`system_id+ended_at`, `status+ended_at`, most likely the node sweeper and stale-call paths in c2-core). - Delete the redundant ASC copies once nothing references them. - Longer term, whatever automates server-26#13 should fail loudly on drift instead of prompting interactively. Note for anyone running the deploy: `infra/firestore/firebase.json` now pins `"database": "c2-server"`. Without that key the CLI targets `(default)`, reports success, and changes nothing the app can see.