feat(artists): account_id override for DELETE /api/artists/{id}

[sweetmantech]

Implements the first flagged endpoint in the admin account-override work: DELETE /api/artists/{id} now accepts an optional account_id override.

What changed

lib/artists/validateDeleteArtistRequest.ts:

• Parses an optional account_id (UUID) from the request body via safeParseJson + a Zod schema.
• Threads it into validateAuthContext(request, { accountId }) — the single chokepoint that authorizes the override (validateAccountIdOverride → canAccessAccount, which already grants Recoup org members universal access).
• Uses the resolved account for the existing checkAccountArtistAccess check.
• Returns 400 for a malformed account_id.

Mirrors the override pattern already shipped on POST /api/artists. No special admin header — auth (who you are) stays separate from authorization (what you can access).

TDD

• Added two failing tests first (override threaded to validateAuthContext + resolved-account access; 400 for invalid UUID) and updated the existing auth-error assertion to the new call signature — confirmed RED, then GREEN.
• Full lib/artists suite: 95 passed. Lint clean on changed files.
• (Pre-existing, unrelated tsc errors live in lib/tasks / lib/trigger test files — not touched here.)

Done when

• Admin calls DELETE /api/artists/{id} with { "account_id": "<target>" } → artist removed.
• Non-admin passing an inaccessible account_id → still 403.

(Verified against the preview deployment in a follow-up comment.)

Merge order

Docs contract lands first: recoupable/docs#247 → then this PR to test.

Tracking issue: recoupable/chat#1811

---

Summary by cubic

Adds an optional account_id override to DELETE /api/artists/{id} so admins and org members can delete an artist in another account’s context. Supports the admin account-override work in chat#1811 and keeps unauthorized deletes blocked.

• New Features
  • Parse optional account_id (UUID) from JSON body; return 400 if invalid.
  • Pass override to validateAuthContext(request, { accountId }) and use the resolved account for checkAccountArtistAccess.
  • Non-admins using an inaccessible account_id still get 403; mirrors POST /api/artists.

^{Written for commit b898f00. Summary will update on new commits.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
api	Ready	Preview	Jun 23, 2026 12:13pm

[coderabbitai]

Warning

Review limit reached

@sweetmantech, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 30 minutes and 26 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate.

For paid Pro and Pro+ PR reviews, CodeRabbit uses rolling per-developer review limits. Reviews become available again as older review attempts age out of the rolling limit window.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 8b8005a5-5af6-41d3-9c4e-897577523eb7

📥 Commits

Reviewing files that changed from the base of the PR and between acae4d8 and b898f00.

⛔ Files ignored due to path filters (1)

• lib/artists/__tests__/validateDeleteArtistRequest.test.ts is excluded by !**/*.test.*, !**/__tests__/** and included by lib/**

📒 Files selected for processing (1)

• lib/artists/validateDeleteArtistRequest.ts

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/delete-artist-account-override

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cubic-dev-ai]

1 issue found across 2 files

Confidence score: 3/5

• In lib/artists/validateDeleteArtistRequest.ts, malformed JSON is treated as empty input, so an intended account_id override can be dropped and deletion may run under the default auth context, risking deletion in the wrong account scope; fail fast on JSON parse errors (e.g., return 400) and add a test for malformed bodies before merging.

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="lib/artists/validateDeleteArtistRequest.ts">

<violation number="1" location="lib/artists/validateDeleteArtistRequest.ts:39">
P2: Malformed JSON request bodies bypass validation and proceed as empty input. This can ignore a caller’s intended `account_id` override and run deletion under the default auth context.</violation>
</file>

Architecture diagram

sequenceDiagram
    participant Client as API Client
    participant Route as DELETE /api/artists/{id}
    participant Validator as validateDeleteArtistRequest
    participant JsonParser as safeParseJson
    participant Schema as Zod Body Schema
    participant Auth as validateAuthContext
    participant AccountOverride as validateAccountIdOverride
    participant Access as canAccessAccount
    participant ArtistCheck as checkAccountArtistAccess
    participant DB as Database / Supabase

    Note over Client,DB: DELETE /api/artists/{id} with optional account_id override
    
    Client->>Route: DELETE /api/artists/{id}
    Route->>Validator: validateDeleteArtistRequest(request, id)
    
    Validator->>Validator: validateAccountParams(id)
    alt Invalid account params (e.g., missing id)
        Validator-->>Route: Return 400 error
        Route-->>Client: 400 Bad Request
    end
    
    Validator->>JsonParser: safeParseJson(request)
    JsonParser-->>Validator: Parsed body (or null)
    
    Validator->>Schema: safeParse(parsedBody)
    
    alt Invalid account_id (not a valid UUID)
        Schema-->>Validator: Validation error
        Validator-->>Route: Return 400 with error message
        Route-->>Client: 400 Bad Request
    else Valid body (account_id optional, may be undefined)
        Schema-->>Validator: { account_id?: string }
    end
    
    Validator->>Auth: validateAuthContext(request, { accountId: parsedBody.account_id })
    
    alt Account override provided
        Auth->>AccountOverride: validateAccountIdOverride(request, overrideId)
        AccountOverride->>Access: canAccessAccount(overrideId)
        Note over Access: Recoup org members get universal access
        Access-->>AccountOverride: Granted / Denied
    else No override (normal flow)
        Auth->>Auth: Normal auth with request cookies/headers
    end
    
    alt Auth failure
        Auth-->>Validator: Return NextResponse (403 Unauthorized)
        Validator-->>Route: Forward auth error
        Route-->>Client: 403 Forbidden
    else Auth success
        Auth-->>Validator: { accountId: resolvedAccoundId, authToken, orgId }
    end
    
    Validator->>ArtistCheck: checkAccountArtistAccess(resolvedAccountId, artistId)
    ArtistCheck->>DB: Query artist access
    DB-->>ArtistCheck: Access result
    
    alt Artist does not exist or no access
        ArtistCheck-->>Validator: False
        Validator-->>Route: Return 404
        Route-->>Client: 404 Not Found
    else Access granted
        ArtistCheck-->>Validator: True
        Validator->>DB: selectAccounts (verify artist exists)
        DB-->>Validator: Account record
    end
    
    Validator-->>Route: { artistId, requesterAccountId }
    Route->>DB: DELETE artist record
    DB-->>Route: Deletion confirmed
    Route-->>Client: 200 OK / Success

Loading

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P2: Malformed JSON request bodies bypass validation and proceed as empty input. This can ignore a caller’s intended account_id override and run deletion under the default auth context.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At lib/artists/validateDeleteArtistRequest.ts, line 39:

<comment>Malformed JSON request bodies bypass validation and proceed as empty input. This can ignore a caller’s intended `account_id` override and run deletion under the default auth context.</comment>

<file context>
@@ -26,7 +36,22 @@ export async function validateDeleteArtistRequest(
   }
 
-  const authResult = await validateAuthContext(request);
+  const body = await safeParseJson(request);
+  const bodyResult = deleteArtistBodySchema.safeParse(body);
+  if (!bodyResult.success) {
</file context>

[sweetmantech]

Manual testing on preview — ✅ passed

Tested the account_id override on DELETE /api/artists/{id} against the preview deploy https://api-git-feat-delete-artist-account-override-recoup.vercel.app with a Recoup admin Bearer token. Branch was first synced with latest main (merged main→test, then test→this branch); PR diff stays scoped to the two delete-artist files.

#	Case	Request	Result
1	Invalid account_id	DELETE /api/artists/{uuid} body {"account_id":"not-a-uuid"}	400 account_id must be a valid UUID — rejected by the new Zod schema before auth/delete ✅
2	Admin override delete (happy path)	DELETE /api/artists/5b60e8be-… body {"account_id":"1724aee2-…"}	200 {"success":true,"artistId":"5b60e8be-…"} ✅
3	Post-delete state	re-list GET /api/artists?account_id=1724aee2-…	roster 10 → 9; deleted artist absent; canonical record + other duplicates intact ✅
4	Cascade / idempotency	repeat request #2	404 Artist not found — the artist account was actually deleted, not just unlinked ✅

What this proves: the override resolves the effective account to the owner (1724aee2-…) through validateAuthContext → canAccessAccount, so checkAccountArtistAccess passes and deleteArtist removes the owner's account_artist_ids link (and deletes the artist account as the last owner). This is the 500→200 fix — without the override, an admin deleting an artist they don't personally own hits deleteAccountArtistId(adminAccount, artistId) with no row to remove and throws Failed to delete artist link (500). That negative path is covered by the unit tests added in this PR.

Safe target selection: 5b60e8be-… was an empty junk duplicate (0 socials / 0 posts / 0 fans, no image, lowercase-typo "Sound of fractures" name). The canonical artist (27a8c5a1-…, real X social w/ ~3.6k followers) and all populated duplicates under the same owner were left untouched.

Not covered (no non-admin token on hand): the negative authz case — a non-admin passing an inaccessible account_id should still 403 via canAccessAccount. Worth a quick follow-up check with a non-admin key. Tracked in recoupable/chat#1811.

Tested 2026-06-23 against branch head (synced with main).

[sweetmantech]

Non-admin rejection — ✅ verified on prod

Follow-up to the admin happy-path testing above. Now that the override is live on prod, verified the negative authz path with a freshly minted non-admin agent key (POST /api/agents/signup, account 15359a7a-…).

Test	Request	Result
Override rejection (the new code path)	DELETE /api/artists/{nonexistent-uuid} body {"account_id":"<inaccessible account>"}	403 Access denied to specified account_id ✅
Baseline non-owner (no override)	DELETE /api/artists/{real artist the key doesn't own} no body	403 Unauthorized delete attempt ✅

The override rejection returns 403 before any artist lookup — validateAuthContext(request, { accountId }) → validateAccountIdOverride → canAccessAccount denies a non-admin's override regardless of target. So a non-admin can't use the new account_id param to act on an account it can't access; the result generalizes to real targets too. A non-existent target was used to keep the test zero-risk — a 404 would have signalled the override was wrongly accepted. No deletion occurred in either case (both 403s fire before deleteArtist).

Tested 2026-06-23 against prod (recoup-api.vercel.app).