fix(socials): drop the dead account_socials.id from /socials (keep social_id)

[sweetmantech]

Part of recoupable/chat#1833 (enabler; same pattern as api#734). Base: main.

Problem

/api/artists/{id}/socials returns each profile with both id (account_socials.id, link row) and social_id (the socials PK). But POST /api/socials/{id}/scrape (and sub-resources) key on social_id — using the id field returns 404 "Social profile not found" for every platform (verified live on all of Apache's socials).

The id is functionally dead: only React key props + a docs entry referenced it; scrape + updateArtistSocials use social_id / the nested social.id (the PK).

Fix

• Drop id from AccountSocialResponse + flattenAccountSocials; keep social_id as the single identity.
• No api consumer read the response id (verified). Companion chat PR switches the two React keys (GetArtistSocialsResult.tsx, ArtistSocial.tsx) from social.id → social.social_id — merge that first (or concurrently) to avoid a transient key-warning.

Tests (TDD)

• New RED→GREEN flattenAccountSocials.test.ts: returns social_id, drops id.
• lib/account + lib/artist suites green (152); tsc + eslint clean (no socials-id type errors anywhere).

🤖 Generated with Claude Code

---

Summary by cubic

Remove the dead link-row id from /api/artists/{id}/socials and standardize on social_id, matching scrape endpoints and preventing 404s.

• Bug Fixes
  • Dropped id from AccountSocialResponse and flattenAccountSocials; return social_id only.
  • Added test to ensure social_id is present and id is omitted.

^{Written for commit 4af5158. 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	Jul 1, 2026 10:01pm

[coderabbitai]

Warning

Review limit reached

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

Next review available in: 58 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

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 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 configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 55b5f032-8c69-4507-8f70-dfc52e300406

📥 Commits

Reviewing files that changed from the base of the PR and between 756252a and 4af5158.

⛔ Files ignored due to path filters (1)

• lib/account/__tests__/flattenAccountSocials.test.ts is excluded by !**/*.test.*, !**/__tests__/** and included by lib/**

📒 Files selected for processing (1)

• lib/account/flattenAccountSocials.ts

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/socials-id-consistency

---

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]

No issues found across 2 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

Architecture diagram

sequenceDiagram
    participant Client as React UI
    participant ArtistsAPI as GET /api/artists/{id}/socials
    participant Flatten as flattenAccountSocials
    participant DB as Database
    participant ScrapeAPI as POST /api/socials/{id}/scrape

    Note over Client,ScrapeAPI: Socials retrieval and scrape flow

    Client->>ArtistsAPI: Request socials for artist
    ArtistsAPI->>DB: SELECT account_socials + socials (joined)
    DB-->>ArtistsAPI: Rows with account_socials.id, social_id, social data
    ArtistsAPI->>Flatten: Transform rows to response objects
    Flatten-->>Flatten: CHANGED: Drop account_socials.id, keep only social_id
    Flatten-->>ArtistsAPI: AccountSocialResponse[] (no id field)
    ArtistsAPI-->>Client: JSON array with social_id, username, etc.

    Note over Client,ScrapeAPI: Client uses social_id for scrape (not dead id)

    alt Client uses social_id (correct)
        Client->>ScrapeAPI: POST with social_id = "soc-1"
        ScrapeAPI->>DB: Lookup social profile by social_id
        DB-->>ScrapeAPI: Found (social row)
        ScrapeAPI-->>Client: 200 Success
    else Before fix: Client might use account_socials.id (dead field)
        Note over Client: Old response included id (account_socials.id)
        Client->>ScrapeAPI: POST with id = "account-social-1"
        ScrapeAPI->>DB: Lookup social profile by account_socials.id
        DB-->>ScrapeAPI: Not found (scrape expects social_id)
        ScrapeAPI-->>Client: 404 "Social profile not found"
    end

    Note over Client,ScrapeAPI: Fix: Response now omits id, client only sees social_id

Loading

<sub>Requires human review: Dropping a field from a response type changes the API contract; even though the field was unused, it's a breaking change that requires human validation of downstream consumers and documentation.

Re-trigger cubic</sub>

[sweetmantech]

Preview verification — /socials drops the dead id; scrape footgun closed

Tested this PR's preview (https://api-i84addxbq-recoup.vercel.app, head 4af5158a) vs test-recoup-api.vercel.app (= main) with the same token, Apache socials as the fixture.

Contrast — before/after

check	#735 preview (fixed)	main (buggy)
/socials first-social keys	no id — only social_id (7c99a023)	both id (04b864b8) + social_id
POST /api/socials/{social_id}/scrape	✅ HTTP 200 (runId)	200
POST /api/socials/{old id 04b864b8}/scrape	HTTP 404 "Social profile not found"	404

The dropped id (04b864b8 = account_socials.id) is exactly the one that 404s on scrape; social_id (7c99a023) works. #735 removes the dead field so a client (or agent) can't grab the wrong one — mirrors the /api/artists fix (api#734).

Docs reconciliation (releases.json → /api/artists/{id}/socials)

Documented socials[] fields: avatar, bio, follower_count, following_count, id, profile_url, region, social_id, updated_at, username.

• ✅ Every field the preview returns (social_id, username, profile_url, avatar, follower_count, following_count, bio, region, updated_at) matches the docs.
• ⚠️ The docs still document id — which fix(socials): drop the dead account_socials.id from /socials (keep social_id) #735 removes. So this introduces one docs↔API drift (opposite direction from fix(artists): /api/artists id must equal account_id (drop leaked account_info.id) #734): the /api/artists/{id}/socials docs should drop id from the schema. Fold into the same small docs-reconciliation follow-up as fix(artists): /api/artists id must equal account_id (drop leaked account_info.id) #734.

Companion: chat#1834 switches the React keys social.id → social.social_id — merge together (chat first or concurrently) so the UI doesn't key on the now-removed field.

Net: #735's contract fix is verified live — the dead id is gone, social_id is the single identity, and scrape works with it (404 only on the old dead id). Docs follow-up: remove id from the /socials schema.