fix(tasks): DELETE /api/tasks honours the account_id admin override

[sweetmantech]

Implements docs#283 and closes the DELETE override row of chat#1918.

Merge order: docs#283 first, then this. The docs PR is the contract; this fulfills it exactly.

The bug

validateDeleteTaskRequest.ts called:

const authContext = await validateAuthContext(request);   // no override options

while the PATCH sibling (validateUpdateTaskRequest.ts L47) passes { accountId: validationResult.data.account_id }. DELETE was the only task verb missing it, so an org or admin key could create, read and edit a member account's task but got 403 deleting it.

Hit live twice — 2026-07-29 removing a duplicate task, and again 2026-07-30 during the task audit. The workaround both times was PATCH {enabled:false} (whose re-sync also deletes the Trigger schedule, so it is at least drift-free).

The fix

• deleteTaskBodySchema gains an optional account_id, using the same description wording as updateTaskSchemas so the two verbs read identically: "Account context for org/API-key rules; authorized via validateAuthContext. Not a raw column override."
• validateDeleteTaskRequest forwards it to validateAuthContext, which keeps ownership of the authorization decision. No new authorization logic is introduced here — a non-admin cross-account delete still 403s, because that check lives in validateAuthContext and is unchanged.

required stays ["id"]; callers that don't send account_id are unaffected.

Tests

RED→GREEN, 2 new tests in lib/tasks/__tests__/validateDeleteTaskRequest.test.ts:

test	asserts
forwards body account_id to validateAuthContext as the override	the fix
rejects a non-UUID account_id with 400	the new field is validated, not passed through raw

Both confirmed RED before the change (expected "spy" to be called with… and expected { …(2) } to be an instance of NextResponse).

• pnpm exec vitest run lib/tasks → 16 files, 78 tests, all pass
• pnpm exec eslint on all three touched files → clean
• pnpm exec tsc --noEmit → no errors in any touched file

Remaining verification

The issue's Done-when asks that DELETE with a valid admin account_id removes the task and its Trigger schedule, and that a non-admin cross-account DELETE still 403s. Both need exercising against the preview before the row is closed — the unit tests cover the wiring, not the live authorization path.

🤖 Generated with Claude Code

---

Summary by cubic

Fixed DELETE /api/tasks to honor the account_id admin/org override, matching GET/POST/PATCH per docs#283. Admin and org API keys can delete member-account tasks; non-admin cross-account deletes still 403.

• Bug Fixes
  • Added optional account_id to the delete body and validate it as a UUID.
  • Forward the override to validateAuthContext; no new auth logic introduced.
  • Added tests for forwarding the override and returning 400 on invalid UUID.

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

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
api	Ready	Preview	Jul 31, 2026 12:39am

[coderabbitai]

Warning

Review limit reached

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

Next review available in: 44 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 Plus

Run ID: abc32d30-b98e-4a3d-81c6-912d6f7aba9f

📥 Commits

Reviewing files that changed from the base of the PR and between f38823c and 208e9d6.

⛔ Files ignored due to path filters (1)

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

📒 Files selected for processing (2)

• lib/tasks/validateDeleteTaskBody.ts
• lib/tasks/validateDeleteTaskRequest.ts

---

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 3 files

Confidence score: 5/5

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

<sub>Auto-approved: Bug fix aligning DELETE with existing GET/POST/PATCH behaviour by forwarding the optional account_id override. Focused change with tests, no new auth logic.

Re-trigger cubic</sub>