Drop legacy task-html storage bucket#391
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
✅ Files skipped from review due to trivial changes (1)
📝 WalkthroughWalkthroughThis PR clears dangling ChangesStorage Bucket Cleanup
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Release VersionsApp patch: ChangelogChanged
|
|
Updates to Preview Branch (work/drop-task-html-bucket) ↗︎
Tasks are run on every commit but only new migration files are pushed.
View logs for this Workflow Run ↗︎. |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (1)
docs/plans/page-content-storage-plan.md (1)
196-199: ⚡ Quick winDo a consistency pass so this plan has one canonical storage path.
This section now correctly says R2 is canonical, but other sections still describe Supabase Storage as the active upload target. Please align the remaining sections to avoid contradictory operator guidance.
🤖 Prompt for 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. In `@docs/plans/page-content-storage-plan.md` around lines 196 - 199, Several sections still describe Supabase Storage (the `task-html` bucket) as the active upload target while the plan's canonical storage is Cloudflare R2 via `ARCHIVE_BUCKET` (production: `native-hover-archive`); update the document so R2 is the single source of truth. Locate all references to `task-html`, "Supabase Storage", or instructions that tell operators to upload/read page HTML from Supabase and replace them with the R2 workflow: mention `ARCHIVE_BUCKET` as the configured env var, update examples and CLI/config snippets to use the R2 path/keys, remove any "active upload target" language for Supabase or mark it explicitly as historical/superseded, and ensure the "## 3. Recommended Approach" section and any upload/read procedures are consistent with the R2 design.
🤖 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 `@CHANGELOG.md`:
- Line 34: Replace the typo phrase "written direct to Cloudflare R2" with
"written directly to Cloudflare R2" in the CHANGELOG entry so the wording reads
correctly; search for the exact string "written direct to Cloudflare R2" and
update it to "written directly to Cloudflare R2".
In `@docs/plans/page-content-storage-plan.md`:
- Around line 201-204: The superseded/historical section still lists
active-sounding bucket settings—remove the stale bullets referencing the
`task-html` bucket (bucket name: `task-html`, visibility: private, access:
signed URLs only) or convert them to an explicit archived note; update the
`task-html` bullet list to either delete these entries or prefix them with a
clear "Archived / Historical" label and brief context so readers know they are
no longer current guidance.
In `@supabase/migrations/20260521000000_drop_task_html_bucket.sql`:
- Line 17: The migration file 20260521000000_drop_task_html_bucket.sql contains
a destructive statement "DELETE FROM storage.buckets WHERE id = 'task-html';"
which violates the additive-only migration rule; replace this destructive delete
with a non-destructive deprecation step (e.g., update a bucket metadata/flags
column or insert a deprecation record) or, if deletion is required, add an
explicit approved-exception record and reference it in the migration (capture
approval id or ticket) before merging; locate the DELETE statement in
20260521000000_drop_task_html_bucket.sql and either change it to an
UPDATE/INSERT that marks the 'task-html' bucket as deprecated/inactive or add
the documented approved-exception metadata so the destructive delete is
explicitly allowed.
- Around line 15-17: Wrap the two statements — the DROP POLICY IF EXISTS
"Service role can manage task html" ON storage.objects and DELETE FROM
storage.buckets WHERE id = 'task-html' — in an explicit transaction so they run
atomically; open a transaction (e.g., BEGIN or START TRANSACTION), run both
statements, and COMMIT at the end (so if the DELETE fails the DROP is rolled
back), ensuring proper semicolons and error-safe transactional semantics.
---
Nitpick comments:
In `@docs/plans/page-content-storage-plan.md`:
- Around line 196-199: Several sections still describe Supabase Storage (the
`task-html` bucket) as the active upload target while the plan's canonical
storage is Cloudflare R2 via `ARCHIVE_BUCKET` (production:
`native-hover-archive`); update the document so R2 is the single source of
truth. Locate all references to `task-html`, "Supabase Storage", or instructions
that tell operators to upload/read page HTML from Supabase and replace them with
the R2 workflow: mention `ARCHIVE_BUCKET` as the configured env var, update
examples and CLI/config snippets to use the R2 path/keys, remove any "active
upload target" language for Supabase or mark it explicitly as
historical/superseded, and ensure the "## 3. Recommended Approach" section and
any upload/read procedures are consistent with the R2 design.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: bffa4f2c-d987-448c-8e3f-c84dbfbf3192
📒 Files selected for processing (3)
CHANGELOG.mddocs/plans/page-content-storage-plan.mdsupabase/migrations/20260521000000_drop_task_html_bucket.sql
|
🐝 Review App Deployed Homepage: https://hover-pr-391.fly.dev |
|
🐝 Review App Deployed Homepage: https://hover-pr-391.fly.dev |
|
🐝 Review App Deployed Homepage: https://hover-pr-391.fly.dev |
Drop legacy task-html storage bucket
Summary
supabase/migrations/20260521000000_drop_task_html_bucket.sqlwhich removes the service-role RLS policy onstorage.objectsforbucket_id = 'task-html'and deletes the bucket row fromstorage.buckets.CHANGELOG.md(Unreleased) with the rationale and operational precondition.docs/plans/page-content-storage-plan.mdas historical/superseded.Why
Page HTML has been written direct to Cloudflare R2 since 2026-04-25 (issue #332). No Go code path still references the
task-htmlSupabase Storage bucket, but the bucket retained the objects written during the four-week window when it was the hot store. The accumulated bytes pushed the Supabase project past its 100 GB storage allowance, which triggered Supabase's connection-slot restriction and surfaced in Sentry aspgconn.ConnectError: FATAL: remaining connection slots are reserved for roles with the SUPERUSER attribute(HOVER-JG).Operational precondition (manual step before applying migration)
Bucket contents must be cleared via the Supabase Storage dashboard or API before this migration is applied. The foreign key from
storage.objectstostorage.bucketswill block the migration otherwise — that is the intended safety net.What this PR does NOT do
tasks.html_storage_*columns. Historical rows still reference them and a follow-up PR will review removal once retrieval flows are confirmed unused.Test plan
task-htmlis the bucket consuming the overage (already inspected; objects total ~117 GB).task-htmlbucket from the Supabase Storage dashboard.SELECT * FROM storage.buckets WHERE id = 'task-html'returns zero rows afterwards.Need help on this PR? Tag
@codesmithwith what you need. Autofix is disabled.Summary by CodeRabbit
Documentation
Chores