fix(tasks): admins can fetch any task by id (unblocks customer-prompt-task)

[sweetmantech]

Problem

customer-prompt-task (Trigger.dev worker) calls GET /api/tasks?id=<externalId> to load a customer's scheduled task config. Two things broke it (recoupable/chat#1810):

1. The endpoint became auth-gated in add auth validation to get tasks API #345 — the worker sent no key → 401. (Fixed in the sibling tasks PR: fetchTask now sends x-api-key.)
2. Even with a valid key, the lookup is account-scoped. validateGetTasksQuery resolves account_id from the caller's key and selectScheduledActions filters by id AND account_id. The shared worker key won't own the customer's task → 0 rows. Chicken-and-egg: the worker would need the owner's account_id to pass it, but it's calling fetchTask precisely to learn that.

This PR fixes (2).

Change

In validateGetTasksQuery, when an admin caller queries by id alone (no account_id param), drop account scoping so the single task is returned regardless of owner. Reuses the existing checkIsAdmin (Recoup-org membership) machinery already used for account_id overrides.

• ValidatedGetTasksQuery.account_id is now optional; selectScheduledActions already only filters by account_id when present, so omitting it yields an id-only lookup.
• Non-admin id lookups stay scoped to the authenticated account — no cross-account leak.
• List queries (no id) are unchanged; checkIsAdmin is only called on the id-lookup / override paths.

TDD

• RED: two new tests — admin id-lookup should drop account_id; non-admin id-lookup should stay scoped. Both failed (checkIsAdmin not called on the id path).
• GREEN: minimal branch added. Full lib/tasks suite green (67 tests, incl. 7 here). tsc adds 0 new errors (pre-existing test-mock noise on main unchanged); eslint clean.

Merge order

Docs first: recoupable/docs#245 documents the auth + 401/403/500 + the admin-id behavior. Then this PR. Then the tasks worker PR + a prod deploy with an admin-scoped RECOUP_API_KEY.

Verification

Preview verification (admin key cross-account lookup, 401 without key, non-admin scoping) posted as a follow-up comment.

Fixes part of recoupable/chat#1810.

🤖 Generated with Claude Code

---

Summary by cubic

Admins can now fetch any task by id without providing account_id, unblocking the customer-prompt-task worker. Non-admin id lookups remain scoped to the caller’s account.

• Bug Fixes
  • Update validateGetTasksQuery: for admin + id-only requests, drop account scoping; otherwise keep it.
  • Make ValidatedGetTasksQuery.account_id optional; selectScheduledActions filters by it only when present.
  • Add tests for admin cross-account id lookup and non-admin scoping.
  • No changes to list queries or override rules.

^{Written for commit 6dde8ad. 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 19, 2026 12:43pm

[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 57 minutes and 10 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 adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly.

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: 8b943da6-720a-42ce-8c5c-17f29aed1d59

📥 Commits

Reviewing files that changed from the base of the PR and between 0e42d02 and 6dde8ad.

⛔ Files ignored due to path filters (1)

• lib/tasks/__tests__/validateGetTasksQuery.test.ts is excluded by !**/*.test.*, !**/__tests__/** and included by lib/**

📒 Files selected for processing (1)

• lib/tasks/validateGetTasksQuery.ts

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/tasks-admin-id-lookup

---

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 and usage tips.}

[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 Worker as customer-prompt-task Worker
    participant API as GET /api/tasks
    participant Validate as validateGetTasksQuery
    participant Auth as validateAuthContext
    participant Admin as checkIsAdmin
    participant DB as Database

    Note over Worker,DB: Admin cross-account task lookup flow

    Worker->>API: GET /api/tasks?id=task_ext_123
    Note over Worker,API: Header: x-api-key (admin key)

    API->>Validate: validateGetTasksQuery(request)

    Validate->>Auth: Authenticate caller
    Auth-->>Validate: { accountId: "admin_acc", ... }

    Validate->>Validate: Parse query params (id task_ext_123, no account_id)

    alt id present AND account_id not provided
        Validate->>Admin: checkIsAdmin("admin_acc")
        Admin-->>Validate: true (caller is Recoup org admin)

        Validate->>Validate: Drop account scoping
        Note over Validate: targetAccountId = undefined
    end

    Validate-->>API: { id: "task_ext_123" }
    Note over Validate,API: No account_id in result

    API->>DB: selectScheduledActions(id = "task_ext_123")
    Note over API,DB: No account_id filter → cross-account lookup

    DB-->>API: Task record owned by different account

    API-->>Worker: 200 + Task data

    Note over Worker,DB: Non-admin id-lookup path (unchanged)

    alt id present AND caller is not admin
        Validate->>Admin: checkIsAdmin("regular_acc")
        Admin-->>Validate: false

        Validate->>Validate: Keep default account scoping
        Note over Validate: targetAccountId = authResult.accountId
        Validate-->>API: { id: "task_1", account_id: "regular_acc" }

        API->>DB: selectScheduledActions(id, account_id)
        DB-->>API: Task only if owned by that account
    end

Loading

<sub>Auto-approved: Adds admin cross-account lookup for single tasks by id. Low-risk, well-tested authorization change.

Re-trigger cubic</sub>

[sweetmantech]

DRY - do we already have a shared lib to check for org + admin account gating? If so, we should use the existing libs instead of directly inlining checkIsAdmin. Check neighboring validate functions.

[sweetmantech]

Good check — I looked at the neighbors. A few findings:

The change already calls the shared helper, not inlined logic. checkIsAdmin(authResult.accountId) is the shared lib/admins/checkIsAdmin.ts (→ validateOrganizationAccess(accountId, RECOUP_ORG_ID)). No org-membership query is inlined here.

It's the established neighbor pattern. The closest sibling — lib/tasks/validateGetTaskRunQuery.ts (GET /api/tasks/runs) — uses the identical checkIsAdmin admin-bypass shape, and this same file's existing account_id-override branch already imports and uses checkIsAdmin. I reused that import rather than introducing a new gating call.

The other org helpers don't fit better here:

• lib/organizations/canAccessAccount.ts needs a targetAccountId (caller-vs-target). My case has no target account — an admin reads any task by id, owner unknown until fetched. Using it would mean restructuring to fetch-then-authorize, and it also grants shared-org access (org-mates, not just Recoup admins) — broader than this bugfix's intended scope (issue chat#1810 deliberately scopes to admin-only).
• lib/organizations/isRecoupAdmin.ts is functionally equivalent to checkIsAdmin but via a different query; switching to it would make this validator inconsistent with its lib/tasks siblings.

So I kept checkIsAdmin for neighbor-consistency. Happy to switch to the org-aware canAccessAccount (fetch-then-authorize) if you want org-mates — not just Recoup admins — to read each other's tasks by id; that's a scope decision, so flagging rather than assuming.

[sweetmantech]

✅ Live verification on preview — core behavior exercised

Supersedes my earlier "not exercisable without an admin key" note: tested against api-otintkleh-recoup.vercel.app (built from this PR's HEAD 6dde8ad9) using a real admin Authorization: Bearer token. Token redacted everywhere; no secret echoed.

Fixtures — Patrick's task id = 351fc5b2-99c3-49d6-b660-969f5a15672a; the calling admin account owns 6 other tasks under account fb678396-… (its own).

#	Request (admin Bearer)	Documented	Actual	✅
T1 — cross-account read	GET /api/tasks?id=351fc5b2-…	200, one task	200 status:success, 1 task — id 351fc5b2-…, owner account_id 26cba4e3-…, title "Daily Social Media Trends Report", prompt present	✅
T2 — caller's own scope	GET /api/tasks (no id)	200	200, 6 tasks, all owned by fb678396-… (caller's account)	✅
T3 — contrast = pre-PR behavior	GET /api/tasks?id=351fc5b2-…&account_id=fb678396-…	account-scoped	200, 0 tasks — scoping by the caller's own account excludes Patrick's task	✅
T4 — unknown id	GET /api/tasks?id=000…000	200 empty	200, 0 tasks	✅
T5 — no auth	GET /api/tasks?id=351fc5b2-…	401	401	✅

What this proves

• The fix works (T1): an admin caller (fb678396-…) retrieves a task owned by a different account (26cba4e3-…) by id alone. This is exactly what customer-prompt-task needs.
• It was genuinely broken before (T3): the same lookup scoped to the caller's own account returns 0 rows — the precise failure mode from chat#1810. The PR's admin/id-only branch is what lifts that scope.
• No cross-account leak for non-admins: T3 demonstrates the scoped path still returns empty when account-scoping applies; the non-admin id-lookup path is additionally covered by unit tests (validateGetTasksQuery.test.ts).
• Auth gate intact (T5), unknown ids return empty not error (T4).

cc recoupable/chat#1810 — this is the live confirmation of the api half; full end-to-end (Patrick's message generated) still pending the prod deploy + admin-scoped worker RECOUP_API_KEY.