Uh oh!
There was an error while loading. Please reload this page.
release: feat(socials) — promote POST /api/socials/{id}/scrape to main (#459) - #467
Merged
Conversation
…h auth (#459) * feat: migrate POST /api/social/scrape to /api/socials/{id}/scrape with auth Port the social scrape endpoint to the RESTful nested-plural path used throughout mono/api and retrofit authentication. - New route: app/api/socials/[id]/scrape/route.ts (async params) - New validator: lib/socials/validatePostSocialScrapeRequest.ts bundles path-id UUID validation + validateAuthContext + access check against the social's owning artist accounts (via account_socials). Falls back to auth-only when the social has no linked accounts. - Refactor postSocialScrapeHandler to (request, id) signature - New helper: lib/supabase/account_socials/selectAccountSocialsBySocialId.ts - Delete legacy app/api/social/scrape/route.ts and lib/socials/validateSocialScrapeBody.ts - Tests under lib/socials/__tests__/ covering 200/400/401/403/404/500 Response body { runId, datasetId } preserved byte-for-byte. * fix: enforce social access check + direct z.object schema + infer account_socials row type - validatePostSocialScrapeRequest: return 403 when social has no linked accounts instead of the previous auth-only fallback; also honor direct membership when the caller owns the social. Admin bypass still flows through checkAccountArtistAccess. - Change postSocialScrapeParamsSchema to a direct z.object(...) and infer PostSocialScrapeParams from it. - selectAccountSocialsBySocialId: drop hand-written AccountSocial return type; cast the client to SupabaseClient<Database> locally so the row type flows from the generated Database types. - Tests: cover the new 403 paths (no links, links null) and the direct membership allow-through. * fix: type serverClient at source; throw on DB error in selectAccountSocialsBySocialId - serverClient: type `createClient<Database>` at declaration so every consumer gets row-type inference without local casts. - selectAccountSocialsBySocialId: drop the `as SupabaseClient<Database>` cast, throw on DB error instead of returning `null`, and tighten the return type to `Tables<"account_socials">[]` (no more `| null`). - validatePostSocialScrapeRequest: remove `?? []` fallback so DB errors propagate to the route handler's 500 path instead of masquerading as a 403 "no owners" response. - Tests: replace the "helper returns null -> 403" case with a "helper throws -> propagates" case. - selectAccountCatalogs: fix stale type annotation for `catalogs` relation (1:1, not array) that was hidden by the untyped client. * refactor: drop manual Tables type; rely on serverClient inference * revert: drop unrelated selectAccountCatalogs type fix from this PR Splitting into standalone prep PR — the catalogs relation type was already wrong (1:1 typed as array); it only surfaced here because typing serverClient made inference real. Handling separately so this PR stays scoped to the social scrape endpoint migration. * refactor: drop manual types in selectAccountCatalogs; rely on serverClient inference Collateral to typing serverClient: instead of hand-writing AccountCatalogWithCatalog (previously wrong — catalogs relation is 1:1, not an array), let the inferred return type flow from the typed supabase client. Matches the pattern now used in selectAccountSocialsBySocialId. * restore: JSDoc on selectAccountCatalogs * docs: restore JSDoc on selectAccountSocialsBySocialId * refactor: extract checkAccountSocialAccess helper; collapse inline access walk * refactor: fold social-id filter into selectAccountSocials; inline access check - selectAccountSocials now takes { accountId?, socialId?, offset?, limit? } options, covering both the owner-side listing and the reverse social-id lookup. Drops the separate selectAccountSocialsBySocialId helper. - Inlines checkAccountSocialAccess back into validatePostSocialScrapeRequest; the validator is currently the only caller, so the domain helper added premature indirection. Will extract again when a second endpoint needs it. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * refactor: drop dead direct-ownership branch from scrape access check Socials are always owned by artist accounts, never directly by the caller's user account — the owningAccountIds.includes(callerId) branch could never fire. Access is gated entirely through checkAccountArtistAccess against each owning artist. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * refactor: use shared errorResponse + validationErrorResponse helpers Drop the local errorResponse wrapper in validatePostSocialScrapeRequest — the codebase already exports errorResponse (lib/networking/) and validationErrorResponse (lib/zod/) with the same envelope. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
Contributor
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 16 minutes and 37 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (9)
✨ 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 |
Uh oh!
There was an error while loading. Please reload this page.
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Promote #459 (
feat: migrate POST /api/social/scrape to /api/socials/{id}/scrape with auth) fromtesttomain.Squash of #459 on
test:770a9f3.Test plan
🤖 Generated with Claude Code
Summary by cubic
Moves social scraping to
POST /api/socials/{id}/scrapewith auth and artist-based access checks, replacingPOST /api/social/scrape. Response stays{ runId, datasetId }; adds strict validation and test coverage.Migration
POST /api/socials/{id}/scrape(UUID in path). No request body.POST /api/social/scrape.Refactors
selectAccountSocialsto accept{ accountId?, socialId?, offset?, limit? }and throw on DB errors; updated all call sites.validatePostSocialScrapeRequestfor UUID, auth, existence, and artist-access checks.Written for commit 770a9f3. Summary will update on new commits.