feat(migrations): create apify_scraper_runs digest-batch table (supersedes #41)#47
Conversation
…1855) Supersedes #41, which ALTERed a table that was never created (#39 closed unmerged per the chat#1840 capability-model decision; 42P01 on prod). Creates the table matching api#760's consumer contract (run_id PK, account_id, social_id, platform, batch_id, completed_at, new_post_urls), scoped to digest bookkeeping only — not an ownership map. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
|
Warning Review limit reached
Next review available in: 23 minutes 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: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Updates to Preview Branch (feat/create-apify-scraper-runs-digest) ↗︎
Tasks are run on every commit but only new migration files are pushed.
View logs for this Workflow Run ↗︎. |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
1 issue found across 1 file
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="supabase/migrations/20260709180000_create_apify_scraper_runs.sql">
<violation number="1" location="supabase/migrations/20260709180000_create_apify_scraper_runs.sql:45">
P2: Enable RLS on the table to match the service-wide convention for internal tables containing account-scoped data (error_logs has it; email_send_log added it in the very next migration). Service-role writes bypass RLS, so net behavior is unchanged, but it closes the gap if anon/authenticated roles ever gain INSERT/UPDATE on this table.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
| @@ -0,0 +1,50 @@ | |||
| -- Create apify_scraper_runs: digest-batch bookkeeping for scrape runs | |||
There was a problem hiding this comment.
P2: Enable RLS on the table to match the service-wide convention for internal tables containing account-scoped data (error_logs has it; email_send_log added it in the very next migration). Service-role writes bypass RLS, so net behavior is unchanged, but it closes the gap if anon/authenticated roles ever gain INSERT/UPDATE on this table.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At supabase/migrations/20260709180000_create_apify_scraper_runs.sql, line 45:
<comment>Enable RLS on the table to match the service-wide convention for internal tables containing account-scoped data (error_logs has it; email_send_log added it in the very next migration). Service-role writes bypass RLS, so net behavior is unchanged, but it closes the gap if anon/authenticated roles ever gain INSERT/UPDATE on this table.</comment>
<file context>
@@ -0,0 +1,50 @@
+ platform TEXT, -- 'instagram' | 'tiktok' | 'x' | ... (digest section label)
+ batch_id UUID, -- minted per POST /api/artist/socials/scrape call; siblings share it
+ completed_at TIMESTAMP WITH TIME ZONE, -- set when OUR webhook finished processing this run's results
+ new_post_urls JSONB -- post URLs genuinely new to the platform (diffed against posts BEFORE upsert)
+);
+
</file context>
1 participant
Summary
Schema prerequisite for the one-digest-per-scrape design on recoupable/chat#1855 (PR #2 of 6). Supersedes #41, which
ALTERedapify_scraper_runs— a table that was never created: #39 (the chat#1840 ownership map that would have created it) was closed unmerged on 2026-07-03 when run polling moved to the capability model, so #41's migration fails on prod with42P01: relation "public.apify_scraper_runs" does not exist(verified live 2026-07-09).This PR creates the table instead, matching the consumer contract in recoupable/api#760 (
lib/supabase/apify_scraper_runs/types.ts—run_id,account_id,social_id,platform,batch_id,completed_at,new_post_urls,created_at), which #41's three columns alone would not have satisfied even on an existing table.Why each column (sanity-checked against "reference the source of truth instead")
batch_id— Apify cannot group runs by our scrape call (no run tags, and siblings don't exist yet when the first run's webhook is registered); grouping state must be ours.completed_at— Apify'sSUCCEEDEDsays the scrape finished, not that our webhook processed the results and wrotenew_post_urls; using it would race and mis-assemble digests.new_post_urls— "new" = absent frompostsimmediately before the upsert; the upsert destroys that state moments later, so the diff cannot be re-derived at digest time.account_id/social_id/platform— written at scrape start, read by the digest assembler for section labels and recipient resolution (api#760'sinsertApifyScraperRuns/getScrapeDigestRecipients).Scope guard
Digest bookkeeping only — this is not an ownership/authorization map; the chat#1840 capability-model decision stands (polling auth unchanged). Loose ids, no FKs, no backfill; additive and safe to apply standalone (columns sit unused until api#760 lands).
Tracking issue: recoupable/chat#1855. Merge order: this PR → api#759 → api#760 → api#761 → api#762.
🤖 Generated with Claude Code
Summary by cubic
Create the apify_scraper_runs table to support one-digest-per-scrape batching. Supersedes #41 by creating the table (the previous ALTER failed on prod) and aligns with api#760’s expected schema.
Written for commit 28242b2. Summary will update on new commits.