Add missing storage-bucket creation to the migration chain (drift fix)#710
Add missing storage-bucket creation to the migration chain (drift fix)#710BigSimmo wants to merge 9 commits into
Conversation
The clinical-documents and clinical-images buckets were declared only in supabase/schema.sql. The migration chain created the storage.objects RLS policies that reference them (20260527000000_bulk_ingestion.sql) but never the buckets, so a database built by replaying migrations had policies for buckets that did not exist and uploads failed until the buckets were created out-of-band. Add a migration mirroring schema.sql's bucket inserts (idempotent, on conflict do update set public = false), so a migrated-from-scratch DB and the CI `supabase db reset` replay have the buckets. schema.sql and the drift manifest already declare them, so no reconciliation edit is needed. Verified offline: change-scope classifies it db_changed (so the CI migration replay runs), the inserts mirror schema.sql exactly, prettier skips .sql, and 79 drift/schema/storage unit tests pass. The replay itself (supabase db reset) runs in CI's db-reset-verify job; it is not runnable locally here (no Supabase Docker / provider boundary). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019UQUcNriJUVSGRhWz794RQ
|
Warning Review limit reached
Next review available in: 1 minute Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughUpdates the PR policy workflow to checkout its trusted script from the current base branch tip and adds an idempotent migration for two private storage buckets with size and MIME-type constraints. ChangesStorage bucket setup
Trusted policy checkout
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
Updates to Preview Branch (claude/storage-bucket-migration) ↗︎
Tasks are run on every commit but only new migration files are pushed.
❌ Branch Error • Fri, 17 Jul 2026 18:32:25 UTC View logs for this Workflow Run ↗︎. |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Note Unit test generation is a beta feature. Expect some limitations and changes as we gather feedback and continue to improve it. Generating unit tests... This may take up to 20 minutes. |
1 similar comment
|
Note Unit test generation is a beta feature. Expect some limitations and changes as we gather feedback and continue to improve it. Generating unit tests... This may take up to 20 minutes. |
|
Note Unit test generation is a beta feature. Expect some limitations and changes as we gather feedback and continue to improve it. Generating unit tests... This may take up to 20 minutes. |
CI triageCI failed on this PR. Automated classification of the 2 failed job(s):
Compared with main CI run #2787 (success). Classification is evidence routing, not permission to ignore a failure. Exact quarantined Playwright identities remain governed by the flake ledger. |
|
✅ Created PR with unit tests: #724 |
|
✅ Created PR with unit tests: #725 |
…heckout When a PR is opened before scripts/pr-policy.mjs existed on main, the pull_request_target workflow checked out the exact base.sha (fd79bc8) which predated the script, causing ERR_MODULE_NOT_FOUND. Fix: use github.base_ref (the branch name, e.g. "main") instead of github.event.pull_request.base.sha. This always checks out the current tip of the base branch, ensuring the policy script is always available. The pull_request_target security model is preserved: only base-branch code is checked out, never the PR head.
Head branch was pushed to by a user without write access
|
✅ Created PR with unit tests: #726 |
…eak-OR footgun Follow-through on the memory/task review. Cross-checked every tracked ongoing/recommended task against the current tree and updated the ledgers to match reality: - ingestion-concurrency-fix-workorder: mark deep-memory delete-scoping RESOLVED (producer-scoped model — migration 20260713030000 + #569 + deep-memory.ts cleanupStagedArtifacts). This doc now has no open repository items. - operator-backlog: close the drift-codify forward-migration row (step 1h) — the forward-codify work-order is complete (applied 2026-07-13). Add a new "apply repo-ahead migrations to live" verify row for the three committed-but-unapplied migrations (20260713201542, 20260714110000, 20260717120000). - audit-remediation-plan-2026-07-14: add a dated reconciliation block recording which findings are now DONE in code, which remain open (OWNER:CODE), which are in flight (PRs #708/#710), and which are operator-pending. Also fix a config footgun the review surfaced (audit finding F5): .env.example advertised RAG_TEXT_WEAK_OR_RELAXATION=true, but src/lib/env.ts defaults it to false because it is a known-regressive opt-in experiment (buries some correct docs after re-ranking). Align the example with the safe code default. Docs + one config default only; no runtime code or schema changed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011Zbpyexer9cLgxhrB61RCU
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@supabase/migrations/20260717139000_create_storage_buckets.sql`:
- Line 26: Update the conflict handlers for the managed storage buckets so they
copy name, public, file_size_limit, and allowed_mime_types from excluded. Apply
this change to both clinical-documents at
supabase/migrations/20260717139000_create_storage_buckets.sql lines 26-26 and
clinical-images at lines 36-36.
🪄 Autofix (Beta)
✅ Autofix completed
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: dad604fa-4159-4007-9f12-44d1af0078af
📒 Files selected for processing (1)
supabase/migrations/20260717139000_create_storage_buckets.sql
|
Note Autofix is a beta feature. Expect some limitations and changes as we gather feedback and continue to improve it. Fixes Applied SuccessfullyFixed 1 file(s) based on 1 unresolved review comment. Files modified:
Commit: The changes have been pushed to the Time taken: |
Fixed 1 file(s) based on 1 unresolved review comment. Co-authored-by: CodeRabbit <noreply@coderabbit.ai>
Summary
The last open P2 from the audit — a schema/migration drift.
The
clinical-documentsandclinical-imagesstorage buckets were declared only insupabase/schema.sql(lines 17–40). The migration chain created thestorage.objectsRLS policies that reference them (20260527000000_bulk_ingestion.sql) but never the buckets. So a database built purely by replaying migrations had RLS policies for buckets that don't exist, and uploads failed until the buckets were created out-of-band (dashboard/schema.sql).This adds
supabase/migrations/20260717130000_create_storage_buckets.sql, which mirrorsschema.sql's bucket inserts exactly — idempotent (on conflict (id) do update set public = false), so it's a no-op re-affirmation on the existing production DB and creates the buckets on a fresh migrated DB.schema.sqland the committed drift manifest already declare the buckets, so no reconciliation edit is needed.Verification
db_changed, so CI'sdb-reset-verify(supabase db reset) migration-replay gate runs — that is the authoritative validation.schema.sqlbyte-for-bytedrift-detection,supabase-schema,storage-cleanup-safety,supabase-project).sql(no format-gate impact)supabase db resetneeds the Supabase CLI + Docker, which aren't available in this environment (provider boundary). The replay is validated by the CIdb-reset-verifyjob. Because this touches the storage layer, please give it a careful DB review before merge rather than relying on auto-merge alone.Clinical Governance Preflight
Touches Supabase schema (storage buckets).
Clinical KB Database(sjrfecxgysukkwxsowpy) — unchanged; this only affects the migration chainpublic = falsepublic = falsepreserved, so no privacy/access regression on the existing DBNotes
rag.tsdeadline-composition judgment call.🤖 Generated with Claude Code
https://claude.ai/code/session_019UQUcNriJUVSGRhWz794RQ
Generated by Claude Code
Summary by CodeRabbit
New Features
Chores