1 — CI step. The deploy job SSHes to the VM (authed as the project service account) and git pulls but never touched Firestore, so firestore.rules and every composite index regressed silently. Adds firebase deploy --only firestore:rules,firestore:indexes right after git pull, from infra/firestore/ (firebase.json pins c2-server). ADC auth, additive for indexes (no --force), warn-not-fail. VM prereq:npm i -g firebase-tools once (host has no node yet — step skips with a warning if absent).
2 — Fix the index file itself. The //direction note ("declare everything ASCENDING, Firestore scans either direction") was wrong for these query shapes. useCalls / useIncidents / useAlerts and c2-core search_calls all orderBy(x, 'desc') and every one threw FAILED_PRECONDITION on the live DB until an explicit DESCENDING index existed:
incidents (org_id ASC, started_at DESC) — already live, now declared
All four were created on c2-server with gcloud on 2026-09-08 to unbreak prod; this file now matches, so a firebase deploy is a no-op rather than a destructive diff. The old drift note telling a deployer to answer YES to deleting calls/incidents (org_id, started_at DESC) as "duplicates" is removed — those are the working indexes.
Two commits:
**1 — CI step.** The `deploy` job SSHes to the VM (authed as the project service account) and `git pull`s but never touched Firestore, so `firestore.rules` and every composite index regressed silently. Adds `firebase deploy --only firestore:rules,firestore:indexes` right after `git pull`, from `infra/firestore/` (firebase.json pins `c2-server`). ADC auth, additive for indexes (no `--force`), warn-not-fail. **VM prereq:** `npm i -g firebase-tools` once (host has no node yet — step skips with a warning if absent).
**2 — Fix the index file itself.** The `//direction` note ("declare everything ASCENDING, Firestore scans either direction") was **wrong** for these query shapes. `useCalls` / `useIncidents` / `useAlerts` and c2-core `search_calls` all `orderBy(x, 'desc')` and every one threw `FAILED_PRECONDITION` on the live DB until an explicit DESCENDING index existed:
- `calls (org_id ASC, started_at DESC)` — Archive 503
- `alert_events (org_id ASC, triggered_at DESC)` — /watch Triggered Alerts
- `alert_events (acknowledged ASC, org_id ASC, triggered_at DESC)` — nav alert badge
- `incidents (org_id ASC, started_at DESC)` — already live, now declared
All four were created on `c2-server` with `gcloud` on 2026-09-08 to unbreak prod; this file now matches, so a `firebase deploy` is a no-op rather than a destructive diff. The old drift note telling a deployer to answer YES to deleting `calls/incidents (org_id, started_at DESC)` as "duplicates" is removed — those are the working indexes.
Backend range-filter indexes (`status/ended_at`, `system_id/*`) stay ASCENDING — genuinely direction-agnostic (no orderBy).
Closes #51, addresses #33.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
The deploy job SSHes to the VM (which runs as the project service account) but never touched Firestore, so rules and composite indexes regressed silently after every fix. Add a firebase-tools deploy right after `git pull`, additive for indexes, warn-not-fail on error.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Tbknwttzou4s46PAykmtix
The old //direction note ('ASC serves orderBy desc') was wrong for these query shapes and left useCalls/useIncidents/useAlerts and search_calls throwing FAILED_PRECONDITION. Declare calls/incidents/alert_events (…, DESC) to match the live DB (indexes created via gcloud 2026-09-08). Drop the misleading 'delete these duplicates' drift note.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Tbknwttzou4s46PAykmtix
logan
merged commit 7f4d684966 into main2026-09-07 23:22:38 -04:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Two commits:
1 — CI step. The
deployjob SSHes to the VM (authed as the project service account) andgit pulls but never touched Firestore, sofirestore.rulesand every composite index regressed silently. Addsfirebase deploy --only firestore:rules,firestore:indexesright aftergit pull, frominfra/firestore/(firebase.json pinsc2-server). ADC auth, additive for indexes (no--force), warn-not-fail. VM prereq:npm i -g firebase-toolsonce (host has no node yet — step skips with a warning if absent).2 — Fix the index file itself. The
//directionnote ("declare everything ASCENDING, Firestore scans either direction") was wrong for these query shapes.useCalls/useIncidents/useAlertsand c2-coresearch_callsallorderBy(x, 'desc')and every one threwFAILED_PRECONDITIONon the live DB until an explicit DESCENDING index existed:calls (org_id ASC, started_at DESC)— Archive 503alert_events (org_id ASC, triggered_at DESC)— /watch Triggered Alertsalert_events (acknowledged ASC, org_id ASC, triggered_at DESC)— nav alert badgeincidents (org_id ASC, started_at DESC)— already live, now declaredAll four were created on
c2-serverwithgcloudon 2026-09-08 to unbreak prod; this file now matches, so afirebase deployis a no-op rather than a destructive diff. The old drift note telling a deployer to answer YES to deletingcalls/incidents (org_id, started_at DESC)as "duplicates" is removed — those are the working indexes.Backend range-filter indexes (
status/ended_at,system_id/*) stay ASCENDING — genuinely direction-agnostic (no orderBy).Closes #51, addresses #33.
🤖 Generated with Claude Code
The old //direction note ('ASC serves orderBy desc') was wrong for these query shapes and left useCalls/useIncidents/useAlerts and search_calls throwing FAILED_PRECONDITION. Declare calls/incidents/alert_events (…, DESC) to match the live DB (indexes created via gcloud 2026-09-08). Drop the misleading 'delete these duplicates' drift note. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Tbknwttzou4s46PAykmtix