Session 0094.0 — Transcript

App: ohm Start: 2026-06-09T04-45 (PST) End: 2026-06-09T05-37 (PST) Type: planning-and-executing Status: FINALIZED

Launch prompt (/goal)

Harden the two §9-surfaced framework fragilities as patch release(s) shipped
localhost→PPE→prod: (1) auth.provision_user 500s on a duplicate email — reconcile
by email; (2) the registry/startup reconcile is additive and never prunes removed
projects/collections/entries — add safe prune-on-reconcile that must NOT wipe on a
transient registry read error.

Outcome (one line)

Both fragilities fixed and shipped to OHM prod through the full §9 pipeline: v0.54.1 (provision_user reconciles by email) and v0.55.0 (registry prune-on-reconcile). prod live @ 0.55.0; both 0.55.0 startup prunes a verified no-op (no data loss).

Pre-state

Opened via /goal right after session 0093 finalized. Clean origin/main at f7b93d7 (v0.54.0). Worked in an isolated worktree off origin/main.

Bug 1 — `auth.provision_user` dup-email 500 → v0.54.1 (patch)

Root cause: the Gitea-OAuth callback's provision_user matched a users row only by gitea_id. A human who signed in first via OTC owns an email-only row (gitea_id NULL); a later OAuth sign-in with the same email missed it and INSERTed a duplicate → collided on the idx_users_email case-insensitive unique index → IntegrityError → 500.

Fix: when no gitea_id row exists, reconcile by email and link the OAuth identity (gitea_id/gitea_login/profile) onto the existing row — the mirror of otc.provision_or_link_user. Owner-zero (§6.1) bootstrap applied on link (matching the fresh-insert path); permission_state preserved so linking never changes admission status as a side effect.

Tests: test_provision_user_email_link.py (3) — OTC→OAuth links onto the same row (no 500), fresh OAuth still inserts (granted), returning gitea_id user not duplicated. Ship: PR #50 → merged; tag v0.54.1 + mirror; PPE deploy (deploys.id=31) + e2e regression green → prod (deploys.id=32, live=0.54.1).

Bug 2 — registry reconcile is additive → v0.55.0 (minor)

Root cause: registry.apply_registry upserts but never deletes. A re-pin to a different registry stranded the old project's collections + cached entries as dead rows that, at scale, starved writes (PPE's stale-ecomm 1238-row 524, reset by hand in 0089).

Design (the careful part): the post-029 schema keys the 13 entry-corpus tables on collection_id (not project_id), 7 tables keep project_id, and one non-keyed descendant (thread_messages → threads) exists — established empirically by building the live schema in a temp DB and classifying every table. New projects.prune_absent_projects(config, present_ids) deletes a removed project + its collections + all those rows in one FK-off transaction with a PRAGMA foreign_key_check backstop that rolls back rather than leave a dangling ref (mirrors restamp_default_project / reconcile_default_collection_id).

Safety scoping (each a deliberate decision):

Whole-project granularity only — a present project is untouched (per-entry prune belongs to the best-effort content cache, whose list can transiently fail).
The default project is never pruned, whatever the registry says.
Reached only after a successful parse of a non-empty registry (parse_registry rejects empty; the read raises on transport error), so a transient read can't wipe.
Prune runs ONLY on the full-reconcile triggers — startup + the periodic sweep (prune=True) — never on incidental refreshes (collection create, webhook, in-app create-project; prune=False). This last decision was forced by the test_s3_scope_roles_vertical regression: that test seeds DB projects directly and creating a collection triggers a refresh — pruning there would have wiped them. (In-app create-project DOES write projects.yaml first, so real projects are always registry-backed.)

Tests: test_prune_absent_projects.py (5) — removes an absent project + all its data (FK-integrity backstop asserted), no-op when all present, never removes default (even on empty present set), empty registry rejected, incidental refresh (webhook, prune=False) does NOT prune. Ship: PR #51 → merged; tag v0.55.0 + mirror; PPE deploy (deploys.id=33) — startup prune verified no-op (PPE projects [ohm] + bdd(3) intact) + e2e regression green → prod (deploys.id=34, live=0.55.0). Prod projects [ohm, ecomm, rfc-app] all survived the prune (the session-0090 dogfood rfc-app project is in projects.yaml).

Cut state

origin ben.stull/rfc-app main = c3efe89; tags v0.54.1 + v0.55.0 on origin
- benstull mirror; mirror main fast-forwarded.
OHM prod live @ v0.55.0 (deploys.id=34); PPE @ v0.55.0 (deploys.id=33). Pins: prod .rfc-app-version=0.55.0, PPE .rfc-app-version.ppe=0.55.0.
backend 685 green (+8 across the two fixes); no migrations.
Worktree removed; no open PRs. Local main checkout left at ff88be2 (behind origin) — untouched.

Deferred decisions

Owner-zero bootstrap on the email-link path (bug 1): applied it so an owner-login human who OTC'd first still becomes owner on OAuth (matches the fresh-insert path). Preserved permission_state rather than auto-granting a pending OTC row on link — the minimal, no-admission-change choice. Low-confidence on the grant question; preserve felt safest.
Prune scoped to startup + sweep only (bug 2): chose not to prune on every refresh_registry (incidental refreshes add wipe-risk for no benefit, and broke the s3 vertical). Trade-off: a registry edit removing a project is reconciled at the next startup / periodic sweep, not instantly. Acceptable — the incident is a re-pin (a restart).
Shipped as two separate releases, not one bundle — isolates the destructive prune (0.55.0) from the safe auth fix (0.54.1) for blast-radius. Cost: two PPE→prod cycles.
PPE metadata.spec SLICE-3 is red on PPE from stale-seed drift (prior runs mutated bdd priorities; the spec needs a fresh seed) — unrelated to either change; main-view-ask.spec.js (the auth/sign-in-exercising regression) is green on PPE for both releases.

Plan

(Two §9 fragilities, two focused releases each crossing localhost→PPE→prod — see the bug sections above for the realized design.)

Next-session prompt

The §9-fragility backlog is now empty. Next is a fresh roadmap pick:

/goal Pick the next milestone from ohm-rfc's roadmap (Phase G / next item) and execute it, per the ohm-rfc roadmap repo. (Optionally instead: the deferred full G-5 write-family slug de-dup — slug-keyed branch/thread/change/PR tables → collection-scoped — the larger migration G-15 left out.)

6.7 KiB Raw Blame History