Commit Graph
4 Commits
Author SHA1 Message Date
Logan CusanoandClaude Sonnet 5 8a0412b529 firestore: add the alert_events composite index (#51)
collectionGroup alert_events (acknowledged, org_id, triggered_at desc) — the index the /watch Triggered Alerts tab and the site-wide useUnacknowledgedAlerts hook require. Still needs a manual deploy; no automation exists (#51).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Claude-Session: https://claude.ai/code/session_01Tbknwttzou4s46PAykmtix
2026-09-07 18:54:10 -04:00
Logan CusanoandClaude Opus 5 187b8c1500 Declare and create the calls(system_id, started_at) index dedup needs
Dedup was failing on essentially every inbound call in production. dedup.py
queries system_id == X with a started_at range; that composite index was
neither declared in firestore.indexes.json nor present in the live c2-server
database, so the query returned FAILED_PRECONDITION, dedup swallowed it as a
warning, and every duplicate check degraded to "not a duplicate".

While AI is off that only cost duplicate call documents. With a window open it
would have paid Whisper and Gemini twice for every double-heard transmission,
and fed Gate B5's cost measurement a figure that is wrong for a reason
unrelated to the pipeline being measured. Two documents for one transmission is
also the exact input shape that produces a spurious second incident.

The index is created on c2-server and building. This declares it in source so
the file and the live database agree.

Refs server-26#84, #33, #45.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 02:43:21 -04:00
Logan CusanoandClaude Opus 5 7ef5704be2 Make firestore.indexes.json describe the database again
Build & Deploy / Build & push images (push) Successful in 4m4s
Build & Deploy / Deploy to VM (push) Successful in 2m11s
Build & Deploy / Report a failed deploy (push) Skipped
The file had drifted four indexes behind c2-server, so the 2026-08-23 deploy
offered to delete four live indexes and then added ASC copies of two that
already existed as DESC. Reconciled against gcloud's actual list.

Adds the two backend indexes that were live but undeclared and are genuinely
in use -- calls(status, ended_at) for recorrelation_sweep's ended-call scan and
calls(system_id, ended_at) for vocabulary_learner. Deleting either would have
broken a background loop with no frontend symptom.

Declares every index ASCENDING. Firestore scans an index in either direction,
so org_id+started_at ASC already serves the orderBy(started_at, 'desc') that
every frontend hook actually asks for; a matched ASC/DESC pair is one index of
pure write amplification on every call document. The three duplicates now left
undeclared are named in the file header so the next deploy's interactive
delete prompt has a documented answer instead of a guess.

Refs server-26#33.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 12:15:39 -04:00
Logan CusanoandClaude Opus 5 94ce9d48e2 Commit the Firestore security rules that were never in source control
SAAS_PLAN.md's review found the actual finding underneath "no multi-tenancy":
drb-frontend reads Firestore directly from the browser (every hook in lib/
does onSnapshot(collection(db, ...))), so drb-c2-core/app/internal/auth.py
is never in that read path at all. Whatever rules were protecting calls,
incidents, and nodes had been hand-set in the Firebase console -
unversioned, unreviewed, and invisible to anyone reading this repo.

Added infra/firestore/firestore.rules: deny-by-default, with every
tenant-scoped collection (nodes, systems, calls, incidents, alert_events,
alert_rules) gated on resource.data.org_id == request.auth.token.org_id, an
org_id claim that doesn't exist yet - the next commits add it. All client
writes stay denied; c2-core's admin SDK bypasses rules and remains the sole
writer, which was already the architecture. Secret-bearing collections
(node_keys, the new enrollment_tokens) are denied to clients outright rather
than org-scoped, since nothing should ever hand a raw credential to the
browser. trips/trip_events keep their current "signed-in users can read"
shape rather than being pulled into org scoping - that feature isn't
tenant-scoped in this pass (see B7), just hidden from non-founding-org users
in the UI.

Added infra/firestore/firestore.indexes.json for the composite indexes the
org_id-scoped queries will need once the frontend hooks add the equality
filter alongside their existing orderBy/range/array-contains clauses -
without these, those queries fail at runtime with a FAILED_PRECONDITION
"index required" error rather than at review time.

Also extended internal/firestore.py's collection_where() with optional
order_by/limit_to/start_after params (SAAS_PLAN.md item 1, a stated
prerequisite for B2: scoped queries need to stay ordered and bounded, and
the existing helper could only do unordered full-collection scans).
array_contains needed no new code - it was already a pass-through op string
to FieldFilter.

None of this is live yet. Deploying rules/indexes is a manual step
(firebase deploy --only firestore:rules,firestore:indexes --project
<project-id>, from infra/firestore/) - nothing in CI does this. Until it
runs, the console-configured rules are still what's actually enforced, and
these rules reference an org_id claim no token carries yet. Deploy this
alongside (not before) the org_id-stamping commits that follow, or every
read breaks for the current single-org deployment.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-16 21:31:09 -04:00