feat(apify): any authenticated key can poll GET /api/apify/runs/{runId} (chat#1840)

[sweetmantech]

Item 1 of recoupable/chat#1840. No docs or database dependency — docs#262 and database#39 both closed unmerged per the design decision below (the existing docs page already matches the new behavior).

Why

An account-scoped key can start a scrape via POST /api/socials/{id}/scrape but got Forbidden polling its own run — validateGetScraperResultsRequest was admin-only (7/7 Forbidden polls in the issue's production evidence, while docs/skills/task prompts all direct agents to poll).

Decision (2026-07-03, supersedes the owner-or-admin draft)

Any valid API key or Bearer token can poll any run id. Scrape datasets are public social content and Apify run ids are long random strings; possession + a valid credential is sufficient. Authentication still gates the endpoint so anonymous callers can't use it as a free Apify proxy. Admin behavior is unchanged (admins hold valid credentials); backend pollers unaffected.

What

One swap in validateGetScraperResultsRequest: validateAdminAuth → validateAuthContext. 401 (no/both credentials), 400 (bad runId), 200/500 all unchanged in shape. Final diff: 2 files, +17/−19.

Tests (TDD, RED→GREEN)

Validator suite rewritten for the new contract: auth-error propagation, 400 empty runId, any-authenticated-caller passthrough. Full lib/apify + lib/socials suites: 117 passed; tsc --noEmit no new errors vs main; eslint clean.

Done-when — preview verification to follow as a comment

• an account key polls a real runId to completion (no admin token involved) — verified on preview 2026-07-03, results table in comments; scrape-start with an account key was already working in prod (this PR only changes the poll validator)

🤖 Generated with Claude Code

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
api	Ready	Preview	Jul 3, 2026 8:43pm

[coderabbitai]

Warning

Review limit reached

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

Next review available in: 2 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: 27d98e51-4e94-416b-aa3d-e91998eaae9f

📥 Commits

Reviewing files that changed from the base of the PR and between 7faeee1 and 2c1911e.

⛔ Files ignored due to path filters (1)

• lib/apify/__tests__/validateGetScraperResultsRequest.test.ts is excluded by !**/*.test.*, !**/__tests__/** and included by lib/**

📒 Files selected for processing (1)

• lib/apify/validateGetScraperResultsRequest.ts

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/apify-runs-account-scope

---

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]

3 issues found across 7 files

Confidence score: 3/5

• In lib/supabase/apify_scraper_runs/insertApifyScraperRun.ts, a rejected ownership insert promise can bypass the current { error } handling and fail scrape start unexpectedly, so users may see intermittent start failures instead of controlled error handling — wrap the insert path in try/catch before merging.
• In lib/apify/validateGetScraperResultsRequest.ts, collapsing Supabase/query errors (null) and true misses ([]) into the same !run branch can return 404 Run not found for backend failures, which misleads clients and complicates incident triage — separate error vs not-found handling and return the appropriate status/message.
• In types/database.types.ts, missing account_id and social_id foreign-key relationship declarations create schema/type inconsistency versus other tables, increasing the chance of incorrect joins or weaker type safety in generated query code — add the missing account_id -> accounts.id and social_id -> socials.id relationships before merge.

Architecture diagram

sequenceDiagram
    participant Client
    participant ScrapeAPI as POST /api/socials/{id}/scrape
    participant Auth as validateAuthContext
    participant ScrapeHandler as postSocialScrapeHandler
    participant ApifySvc as scrapeProfileUrl
    participant RunDB as apify_scraper_runs
    participant PollAPI as GET /api/apify/runs/{runId}
    participant CheckAdmin as checkIsAdmin

    Note over Client,PollAPI: Account-scoped Apify run ownership & authorization

    Client->>ScrapeAPI: POST /api/socials/{id}/scrape
    ScrapeAPI->>Auth: validateAuthContext(request)
    Auth-->>ScrapeAPI: accountId
    ScrapeAPI->>ScrapeHandler: postSocialScrapeHandler(request, id)
    ScrapeHandler->>ApifySvc: scrapeProfileUrl(...)
    alt Scrape started successfully
        ApifySvc-->>ScrapeHandler: { runId, datasetId }
        Note over ScrapeHandler: NEW: Record ownership
        ScrapeHandler->>RunDB: insertApifyScraperRun({run_id, account_id, social_id})
        Note over ScrapeHandler,RunDB: log-and-continue on error
        RunDB-->>ScrapeHandler: inserted row or null
        ScrapeHandler-->>ScrapeAPI: 200 { runId }
    else Scrape fails to start
        ApifySvc-->>ScrapeHandler: { error: "..." }
        Note over ScrapeHandler: NEW: No ownership recorded
        ScrapeHandler-->>ScrapeAPI: error response
    end

    Client->>PollAPI: GET /api/apify/runs/{runId}
    PollAPI->>Auth: validateAuthContext(request)
    Auth-->>PollAPI: accountId
    PollAPI->>CheckAdmin: checkIsAdmin(accountId)
    alt Admin
        CheckAdmin-->>PollAPI: true
        Note over PollAPI: No ownership lookup for admin
        PollAPI-->>Client: 200 (run data, unchanged)
    else Non-admin
        CheckAdmin-->>PollAPI: false
        PollAPI->>RunDB: selectApifyScraperRuns({runId})
        alt Owner record found and matches caller
            RunDB-->>PollAPI: [{run_id, account_id, ...}]
            PollAPI-->>Client: 200 (run data)
        else Owner record found for different account
            RunDB-->>PollAPI: [{run_id, account_id, …}]
            PollAPI-->>Client: 403 { status:"error", message:"Forbidden" }
        else No owner record (empty or null)
            RunDB-->>PollAPI: [] or null
            PollAPI-->>Client: 404 { status:"error", message:"Run not found" }
        end
    end

Loading

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

Re-trigger cubic</sub>

[sweetmantech]

Preview verification — round 1 (2026-07-03)

Preview https://api-qh1womekr-recoup.vercel.app confirmed built from cbb4d7a7 (deployment 5303721407 queried by sha, status success).

check	expected	observed	verdict
GET /api/apify/runs/{runId}, no credentials	401	401 {"status":"error","error":"Exactly one of x-api-key or Authorization must be provided"} — the new validateAuthContext-first path is live (old code returned the admin 403 here)	✅
prod control: fresh non-admin key on prod endpoint	403 (old admin-only behavior)	403 {"status":"error","message":"Forbidden"}	✅ baseline
fresh non-admin key on preview	404 Run not found	401 Unauthorized — the key (minted via prod /api/agents/signup, verified working on prod /api/accounts/id → 200) is unknown to the preview	⚠️ blocked

The third row is an environment finding, not a code failure: api preview deployments don't share the prod key store — the same key returns 200 on prod and 401 on the #753 preview too, whose auth path is untouched. Account-scoped checks (owner 200 / foreign 403 / unmapped 404) therefore can't be exercised against a preview with a minted key.

Remaining Done-when checks and their gates:

• owner 200 + foreign 403 + unmapped 404 — needs database#39 applied + an environment that shares the key store (the test deployment after merge, or a preview-env admin token).
• admin 200 — needs a fresh admin token (the session token expired mid-verification; the unit suite covers the passthrough).

Unit-level coverage of all five outcomes is in the PR (RED→GREEN). Will post round 2 once the migration lands.

[sweetmantech]

Reworked per design discussion (2026-07-03): moved from owner-or-admin to any authenticated caller — the maintainer's call: scrape data is public social content and run ids are unguessable, so possession + a valid credential is sufficient. The apify_scraper_runs ownership map is gone (database#39 closed unmerged), the diff is now 2 files (+17/−19), and the round-1 preview findings about key-store scoping no longer gate anything except the final live poll check.

[cubic-dev-ai]

0 issues found across 7 files (changes from recent commits).

<sub>Auto-approved: Swaps admin-only auth to any-valid-credential auth for GET /api/apify/runs/{runId}. Isolated change with updated tests and clear design rationale.

Re-trigger cubic</sub>

[sweetmantech]

Preview verification — round 2 (2026-07-03) ✅

Preview https://api-ou561uuwp-recoup.vercel.app confirmed built from the reworked head 6563b83d (deployment 5304134290, queried by sha, state success).

Credential setup: previews share the production Supabase but hash API keys with a preview-specific PRIVY_PROJECT_SECRET (so prod-minted keys never match) and use a separate Privy app — corrected after checking list_projects: godremdq… is the only Supabase project, and POST /api/agents/signup on the preview 500s — preview-env Privy is at its user cap (createPrivyUser → 400 max_accounts_reached, from live function logs; account row is created, key never minted — pre-existing env issue, unrelated to this PR). Workaround: created the account + hashed key rows directly in the preview Supabase via its own service role and PRIVY_PROJECT_SECRET from vercel env pull — byte-identical to what generateAndStoreApiKey writes, skipping only the broken Privy step. Test account: 6c8cec0b-f1b2-40a2-b10f-ddd60f91bb3a (plain account, no admin/org membership).

#	check	expected	observed	verdict
1	GET /api/accounts/id with minted key	200, own accountId	200 {"accountId":"6c8cec0b-…"}	✅
2	Done-when: plain account key polls real TikTok run 9AYX8xyaHWyHtnGtC	200 + data	200 status:SUCCEEDED, dataset wRTf1l626BDzubDNw, 1 item, webVideoUrl: tiktok.com/@brauxelion/video/7516257593208147205	✅
3	same key polls real X run bx3asRqfbNnkKgogG	200 + data	200 status:SUCCEEDED, 1 item	✅
4	no credentials	401	401 {"status":"error","error":"Exactly one of x-api-key or Authorization must be provided"}	✅
5	unknown runId, valid key	(record actual)	200 {"status":"UNKNOWN","dataset_id":null} — pre-existing handler behavior, unchanged by this PR	✅ documented
6	prod control (earlier this session): non-admin key, same poll on prod	403 (old admin gate)	403 {"status":"error","message":"Forbidden"}	✅ baseline

Row 2 is the exact call from the issue's evidence (7/7 Forbidden in production on 2026-07-02) now returning the run's real dataset to a plain account key. Docs ↔ API ↔ live agree: 200/400/500 per the existing Scraper Results page, 401 for anonymous callers (undocumented, consistent with sibling endpoints).

Two inherited env findings, out of scope here: preview Privy app at max_accounts_reached breaks POST /api/agents/signup on previews; previews don't share the prod key store (expected, but worth knowing for future preview testing).