feat(tasks): thread scheduled task titles onto GET /api/tasks/runs list runs#764
feat(tasks): thread scheduled task titles onto GET /api/tasks/runs list runs#764sweetmantech wants to merge 1 commit into
Conversation
…st runs Trigger.dev list runs carry only taskIdentifier (every scheduled prompt shares customer-prompt-task), so chat's homepage rendered identical "Scheduled Task" rows. List mode now annotates each run with the originating scheduled_actions.title, resolved by matching run ids against each schedule's runs (filter[schedule] on trigger_schedule_id — list runs expose no schedule reference, verified against the live v1 API). title is null when a run cannot be mapped; retrieve mode and all existing fields are unchanged. Fails open at both layers: a failed Trigger.dev schedule fetch skips that schedule's titles, a failed scheduled_actions lookup yields null titles — the runs list never breaks. Contract: recoupable/docs#268. Tracking: recoupable/chat#1850 (video-parity item 1). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
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. |
|
Warning Review limit reached
Next review available in: 43 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the 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 configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (3)
📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
1 issue found across 6 files
Confidence score: 3/5
- In
lib/tasks/getTaskRunHandler.ts, list-mode now does work proportional to all scheduled tasks becauseattachRunTitlesfetches every schedule and then calls Trigger.dev per schedule, so large accounts can see slow responses, higher backend load, or request timeouts even when clients ask for a small run limit — cap/batch title enrichment to the requested run limit (or otherwise bound per-request fan-out) 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/tasks/getTaskRunHandler.ts">
<violation number="1" location="lib/tasks/getTaskRunHandler.ts:32">
P2: List-mode requests now scale with the account's total scheduled task count, not the requested run limit, because `attachRunTitles` fetches every scheduled action and then one Trigger.dev run list per schedule. Consider bounding or batching this lookup so a large account cannot make `GET /api/tasks/runs` slow or trip Trigger.dev rate limits.</violation>
</file>
Architecture diagram
sequenceDiagram
participant Client as Client (Next.js frontend)
participant Handler as getTaskRunHandler
participant Supabase as Supabase (scheduled_actions)
participant Trigger as Trigger.dev API
participant Attach as attachRunTitles
participant BuildMap as buildRunTitleMap
Client->>Handler: GET /api/tasks/runs?mode=list&accountId=acc_123&limit=20
Handler->>Handler: validate query (existing)
Note over Handler,Trigger: Existing: Fetch account-tagged runs
Handler->>Trigger: fetchTriggerRuns({filter[tag]: "account:acc_123"}, 20)
Trigger-->>Handler: runs[] (e.g., 2 runs)
Note over Handler,Attach: NEW: Annotate runs with titles
Handler->>Attach: attachRunTitles(runs, acc_123, 20)
alt Empty runs list (short circuit)
Attach->>Attach: return [] immediately
Attach-->>Handler: []
else Success path
Attach->>Supabase: selectScheduledActions({account_id: acc_123})
Supabase-->>Attach: actions[] (with trigger_schedule_id, title)
Attach->>BuildMap: buildRunTitleMap(actions, 20)
loop per action with trigger_schedule_id
BuildMap->>Trigger: fetchTriggerRuns({filter[schedule]: sched_id}, 20)
alt Fetch succeeded
Trigger-->>BuildMap: scheduleRuns[]
BuildMap->>BuildMap: map each run.id → action.title
else Fetch failed
BuildMap->>BuildMap: skip schedule (no entries)
end
end
BuildMap-->>Attach: Map<runId, title>
Attach->>Attach: runs.map(r => ({...r, title: map.get(r.id) ?? null}))
Attach-->>Handler: runsWithTitles[]
else Title resolution error (DB / Trigger.dev outage)
Attach->>Attach: log error, return runs with title: null
Attach-->>Handler: runsWithTitles[] (all null)
end
Handler-->>Client: 200 {status:"success", runs: runsWithTitles}
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
| { "filter[tag]": `account:${validatedQuery.accountId}` }, | ||
| validatedQuery.limit, | ||
| ); | ||
| const runsWithTitles = await attachRunTitles( |
There was a problem hiding this comment.
P2: List-mode requests now scale with the account's total scheduled task count, not the requested run limit, because attachRunTitles fetches every scheduled action and then one Trigger.dev run list per schedule. Consider bounding or batching this lookup so a large account cannot make GET /api/tasks/runs slow or trip Trigger.dev rate limits.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At lib/tasks/getTaskRunHandler.ts, line 32:
<comment>List-mode requests now scale with the account's total scheduled task count, not the requested run limit, because `attachRunTitles` fetches every scheduled action and then one Trigger.dev run list per schedule. Consider bounding or batching this lookup so a large account cannot make `GET /api/tasks/runs` slow or trip Trigger.dev rate limits.</comment>
<file context>
@@ -26,8 +29,13 @@ export async function getTaskRunHandler(request: NextRequest): Promise<NextRespo
{ "filter[tag]": `account:${validatedQuery.accountId}` },
validatedQuery.limit,
);
+ const runsWithTitles = await attachRunTitles(
+ runs,
+ validatedQuery.accountId,
</file context>
Preview verification —
|
1 participant
What
List mode of
GET /api/tasks/runsnow annotates each run withtitle: string | null— the originating scheduled task'sscheduled_actions.title, null when unresolvable. Retrieve mode (runId) and every existing field are unchanged; the addition is purely additive.Why
Trigger.dev list runs carry only
taskIdentifier, and every scheduled prompt sharescustomer-prompt-task— so the chat homepage renders five identical "Scheduled Task" rows (recoupable/chat#1850, video-parity item 1, promoted from the chat#1853 fast-follow note).How runs link to schedules (mechanism)
Trigger.dev's v1 list-runs rows expose no schedule reference (verified against the live API; the
scheduleobject exists only on single-run retrieve). The join is the reverse lookup the repo already uses inenrichTasks: for each of the account'sscheduled_actionswith atrigger_schedule_id, fetch its runs viafilter[schedule]and map run id → title. Verified live: schedule-filtered run ids intersect the account-tag list exactly (run_cmr91tpc0…appears in both forsched_d4o3wm3xskug35izn59ej/ "Weekly Social Media Health Check Report").Per-schedule fetch uses the caller's
limit, which is sufficient coverage: a schedule can contribute at mostlimitruns to the top-limitaccount list.Implementation
lib/tasks/buildRunTitleMap.ts— run id → title map via per-schedulefetchTriggerRuns({ "filter[schedule]": … }); fails open per schedulelib/tasks/attachRunTitles.ts—selectScheduledActions({ account_id })(existing lib/supabase function) → map → annotate; fails open to all-null titles so the runs list never 500s on title resolutionlib/tasks/getTaskRunHandler.ts— list branch pipes runs throughattachRunTitlesOne exported function per file; TDD RED→GREEN per unit (new modules failed collection + handler assertion failed before implementation).
Verification
pnpm exec tsc --noEmit: 200 errors = exact pre-existing baseline, 0 new (measured by stash/compare)pnpm lintclean, prettier cleanscheduled_actions(above)Links
titleon task runs — originating scheduled task's title docs#268feat/home-run-titles(rendersrun.titleinHomeRunRowwith today's label as fallback)🤖 Generated with Claude Code
Summary by cubic
GET /api/tasks/runs list mode now includes a title field per run, set to the originating scheduled task’s title or null if it can’t be resolved. This makes scheduled runs distinguishable in the chat UI; retrieve mode and existing fields are unchanged.
attachRunTitlesandbuildRunTitleMaputilities; list handler pipes runs through title annotation using the request limit for coverage.Written for commit 8c05e16. Summary will update on new commits.