Uh oh!
There was an error while loading. Please reload this page.
feat(wait, workflows): Async toggle, chained-wait resume fix, execution status API - #4514
Conversation
The chained-pause flow leaves a row in 'partially_resumed' status (wait1 done, wait2 still waiting). The poll's WHERE filter only matched 'paused', so wait2 was never picked up. Include 'partially_resumed' in the filter.
The latest updates on your projects. Learn more about Vercel for GitHub.
|
PR SummaryMedium Risk Overview Updates the Wait block to introduce an explicit Fixes chained-wait resumption by having the cron resume poller and Reviewed by Cursor Bugbot for commit 2ba29c6. Bugbot is set up for automated code reviews on this repo. Configure here. |
Greptile SummaryThis PR bundles three wait/pause lifecycle improvements: an explicit Async toggle on the Wait block that separates in-process sleeps (≤5 min) from disk-persisted suspensions (≤30 days), a cron-poll fix that picks up
Confidence Score: 5/5Safe to merge — the cron-poll fix is targeted and the new endpoint introduces no auth bypasses or data leaks. The partially_resumed poll fix is a narrow two-line change with clear before/after semantics, verified against production logs and covered by the existing test suite. The async toggle is additive with an explicit fallback for legacy configs. The new status endpoint reuses the same validateWorkflowAccess middleware as existing paused-execution routes, and its DB queries are scoped by both executionId and workflowId. The resumedCount field is notNull().default(0) in the schema, so the non-nullable Zod field is safe. No data mutation occurs on the GET path. No files require special attention. Important Files Changed
Sequence DiagramsequenceDiagram
participant Client
participant StatusAPI as GET /executions/{id}
participant PollCron as Cron /resume/poll
participant HITLMgr as HumanInTheLoopManager
participant DB
Client->>StatusAPI: "GET ?selectedOutputs=blockId"
StatusAPI->>DB: SELECT workflowExecutionLogs WHERE (executionId, workflowId)
StatusAPI->>DB: SELECT pausedExecutions WHERE executionId
DB-->>StatusAPI: logRow + pausedRow (status: partially_resumed)
StatusAPI-->>Client: "{status: paused, resumeAt, blockedOnBlockId}"
Note over PollCron,DB: Chained-wait resume fix
PollCron->>DB: "SELECT pausedExecutions WHERE status IN ('paused','partially_resumed') AND nextResumeAt <= now"
DB-->>PollCron: partially_resumed row (wait2 due)
PollCron->>HITLMgr: dispatchRow(executionId)
HITLMgr->>DB: setNextResumeAt(null) WHERE status IN ('paused','partially_resumed')
Note right of DB: Previously WHERE status='paused' was a no-op for partially_resumed rows
Note over Client,DB: Async Wait block
Client->>StatusAPI: GET (after async wait completes)
StatusAPI->>DB: SELECT workflowExecutionLogs
DB-->>StatusAPI: status: completed
StatusAPI-->>Client: "{status: completed, finalOutput: ...}"
Reviews (3): Last reviewed commit: "docs(api): tighten getWorkflowExecution ..." | Re-trigger Greptile |
Uh oh!
There was an error while loading. Please reload this page.
Adds WAIT_INPROCESS_MAX_MS env var (default 300000ms = 5 min). Lower it locally (e.g. 5000) to exercise the suspend/cron-resume path with short waits.
Uh oh!
There was an error while loading. Please reload this page.
- setNextResumeAt now matches paused OR partially_resumed; otherwise the cron poller can't null nextResumeAt after dispatching a chained-wait row, so it keeps reappearing in every poll batch until execution ends (flagged by both greptile and bugbot) - Suspend mode now defaults missing timeUnitLong to 'minutes' instead of falling back to 'seconds' and immediately erroring (flagged by bugbot)
TheodoreSpeaks
commented
May 15, 2026
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 4c7bc83. Configure here.
Restores the pre-#4331 description on the Wait Amount field so the limit is visible before submit instead of only at runtime. Mentions both the 5 min default and the 30 day cap with Suspend Workflow.
Uh oh!
There was an error while loading. Please reload this page.
…tus endpoint Normalized status (pending|running|paused|completed|failed|cancelled) across workflowExecutionLogs and pausedExecutions in a single response. Surfaces paused-state details (resumeAt, pauseKind, blockedOnBlockId) when a row exists in pausedExecutions, and the error string for failed runs. finalOutput is opt-in via ?includeOutput=true.
Returns per-block outputs filtered by selectedOutputs paths (same shape as the execute endpoint). Reads from executionData.traceSpans, walks children recursively, and resolves dot-paths into each block's output. Bare blockId returns the full output.
Switch sub-blocks return null from renderLabel (sub-block.tsx:238), so the tooltip never reached the user. The trade-off explanation already lives in longDescription and bestPractices. Flagged by bugbot.
…rtially-resumed # Conflicts: # scripts/check-api-validation-contracts.ts
Adds the WorkflowExecutionStatus schema and the getWorkflowExecution operation to the OpenAPI spec, including completed/paused/failed response examples and the includeOutput + selectedOutputs query params. Registers the page in the Workflows section of the API reference.
TheodoreSpeaks
commented
May 16, 2026
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 2ba29c6. Configure here.
Summary
Three changes bundled in one PR — all related to the wait-block / paused-execution lifecycle.
1. Async toggle on the Wait block (new)
Asyncswitch on the Wait block (off by default)PauseMetadataregardless of duration, up to 30 days, units are minutes/hours/days (seconds disabled)2. Cron poll picks up `partially_resumed` rows
3. New `GET /api/workflows/[id]/executions/[executionId]` status endpoint
Lightweight polling primitive that normalizes execution status across `workflowExecutionLogs` and `pausedExecutions` in one response — bridges the gap between `/api/jobs/{jobId}` (only tracks async-launched jobs, marks complete on first suspend) and `/api/v1/logs/executions/{eid}` (heavy snapshot dump, no live paused state).
Request:
```
GET /api/workflows/{workflowId}/executions/{executionId}
?includeOutput=true (optional — include finalOutput when status=completed)
?selectedOutputs=blockId,blockId.field,blockId.nested.path
X-API-Key:
```
Response:
```jsonc
{
"executionId": "...",
"workflowId": "...",
"status": "pending" | "running" | "paused" | "completed" | "failed" | "cancelled",
"trigger": "manual" | "api" | "schedule" | "webhook" | "chat",
"level": "info" | "warning" | "error",
"startedAt": "...",
"endedAt": "..." | null,
"totalDurationMs": 153035 | null,
"paused": null | {
"pausedAt": "...",
"resumeAt": "...", // earliest next-resume across active pause points
"pauseKind": "time" | "human" | null,
"blockedOnBlockId": "..." | null,
"pausedExecutionId": "...",
"pausePointCount": 1,
"resumedCount": 0
},
"cost": { "total": 0.005 } | null,
"error": "Wait 1: ..." | null,
"finalOutput": { ... } | null, // only when ?includeOutput=true and status=completed
"blockOutputs": { // only when ?selectedOutputs is set
"": { ...full output },
".":
} | null
}
```
Auth uses `validateWorkflowAccess` — same scoping as `/paused`. The URL workflow-scoping and DB `(executionId AND workflowId)` query are belt-and-suspenders against cross-workflow ID typos; the executionId is globally unique. Returns 404 for both unknown executionId and mismatched workflowId/executionId pairs.
When to use what:
Type of Change
Testing
Checklist