docs(ingestion): work-order for remaining phase-3 concurrency fixes#377
Conversation
…cy fixes Captures the state-machine findings that could not be safely landed from a chat session, each grounded in the LIVE catalog (read-only; nothing applied to live) so the coordinated drift-reconciliation release can execute them drift-free: - R2 lease fences on complete/fail RPCs (expand/contract, backward-compatible p_worker_id default null; DB-first, worker deploy follows) - R9 batch-status lost update (lock import_batches row before count+update) - R7 attempt_count clamp / stuck-pending job - R23 job-existence guard inside cleanup delete predicates - R17 partial unique index on open ingestion_jobs + reindex-route 409 handling (coordinate with drift-backlog item #7) - R24e remove the phantom ingestion_job_stages.job_id FK from schema.sql (live has no such FK; supersedes drift-backlog item #8) - R5 worker metadata full-replace → scoped jsonb merge (coordinated) - deep-memory delete-scoping: documented as NOT a small change — document_sections UNIQUE(document_id,section_index) + section_id FK make naive scoping a live crash risk; needs a section-ownership design (retrieval eval-gated) Includes exact live-derived RPC skeletons, per-item deploy ordering, verify/eval gates, and #369/drift-backlog collision notes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Coordination note: PR #380 now implements the RPC-hardening section of this work-order plus R24e, all green (verify + Supabase Preview migration replay + ui-smoke + Gitleaks):
So those sections here can be marked done via #380. Still open per this work-order (unchanged): R17 (open-jobs unique index — drift backlog #7, |
1 participant
Summary
Doc-only. A sequenced, operator-applied work-order for the ingestion-concurrency phase-3 findings that could not be safely landed from a chat session — so the coordinated drift-reconciliation release can execute them. Every fact is read from the live
Clinical KB Databasecatalog (read-onlyexecute_sql; nothing applied to live), and RPC changes are derived frompg_get_functiondefbodies (not the known-driftedschema.sql).Why these weren't just shipped
complete_ingestion_job/fail_or_retry_ingestion_jobtake nop_worker_id).schema.sqlchanges → require Dockerdrift:manifestregen and overlap the active reconciliation backlog indocs/database-drift-detection.md(items Bump @supabase/supabase-js from 2.105.4 to 2.106.1 #7ingestion_jobsindexes, Bump gitleaks/gitleaks-action from 2 to 3 #8 theingestion_job_stagesFK).document_sectionshasUNIQUE (document_id, section_index)+section_idFK, so the naive "preserve agent rows" scope risks a live unique-violation crash / detached cards. Needs a section-ownership design. (Live-verified: 0 docs currently hold both agent and non-agent sections.)What the doc gives the implementer
Per finding: the live-verified facts, an exact live-derived SQL skeleton (expand/contract for the RPC fences), the files touched, deploy ordering, the verify/eval gate, and collision notes vs #369 and the drift backlog. Suggested landing order at the end.
Verification
prettier --checkclean. No code/schema changed.check:indexing,reindex:health,check:production-readiness, andeval:retrieval:quality36/36 (content_mrr@10 = 0.924).Notes
Companion to
docs/ingestion-state-machine.md(§6/§8) anddocs/scale-readiness-review.md. The live database was only read, never written.🤖 Generated with Claude Code