fix(wait): poll partially_resumed rows so chained waits resume

[TheodoreSpeaks]

Summary

• After PR fix(terminal): terminal console update for child spans + hitl state machine #4450, persistPauseResult merges new pause points with existing ones, so a chained-wait workflow ends up with a row in status = 'partially_resumed' (wait1 marked resumed, wait2 still paused) once wait1 finishes.
• The cron poll's WHERE status = 'paused' filter excluded those rows, so wait2 was never dispatched. Verified in prod logs: execution 2e9e4780... had wait1 fire, agent run, then suspended for wait2 — and wait2 sat for 1h+ with next_resume_at long elapsed while every cron tick reported claimedRows: 0.
• Filter now includes partially_resumed alongside paused. Single-pause workflows are unaffected.

Type of Change

• Bug fix

Testing

Tested manually against prod logs. bun run lint clean. bun run check:api-validation:strict passing. Type-check clean.

The existing partial index is gated on status = 'paused' so partially-resumed rows fall through to a sequential scan; volume is small enough that this is acceptable. Widening the index predicate to cover both statuses can be a follow-up if scan time becomes an issue.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

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

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		May 8, 2026 3:23am

[cursor]

PR Summary

Medium Risk
Changes workflow resume selection logic and makes wait in-process threshold configurable, which could affect timing/scheduling and database load for paused execution processing.

Overview
Fixes chained time-wait workflows getting stuck by expanding the /api/resume/poll query to also dispatch due paused_executions rows in status='partially_resumed' (not just paused).

Makes the Wait block’s in-process sleep threshold configurable via new WAIT_INPROCESS_MAX_MS env var (default 5 minutes), keeping the existing behavior by default while allowing easier testing/tuning of the suspend/resume path.

^{Reviewed by Cursor Bugbot for commit 91f88a7. Bugbot is set up for automated code reviews on this repo. Configure here.}

[greptile-apps]

Greptile Summary

This PR fixes a bug where chained-wait workflows (wait1 → agent → wait2) were permanently stalled: after wait1 fired, the row transitions to status = 'partially_resumed', and the cron poll's WHERE status = 'paused' filter never picked it up. The fix widens the filter to inArray(['paused', 'partially_resumed']).

• Core fix: the SELECT query in the cron poll now includes partially_resumed rows via inArray, and the eligibility filter inside dispatchRow correctly skips pause points already in resuming state (guarded by enqueueOrStartResume's own resumeStatus !== 'paused' check).
• Batch-slot leak: setNextResumeAt in human-in-the-loop-manager.ts still guards on WHERE status = 'paused', so after a partially_resumed row is dispatched its next_resume_at is never cleared. The row will re-appear in every subsequent cron batch (consuming a slot from POLL_BATCH_LIMIT = 200) until execution completes.

Confidence Score: 3/5

The chained-wait stall is correctly fixed, but dispatched partially_resumed rows are never removed from the cron queue, potentially starving new paused rows under load.

The setNextResumeAt guard in human-in-the-loop-manager.ts only matches status = 'paused', so every successfully-dispatched partially_resumed row keeps its elapsed next_resume_at and re-enters each cron poll batch indefinitely — consuming batch capacity until execution completes.

apps/sim/lib/workflows/executor/human-in-the-loop-manager.ts — setNextResumeAt at line ~1707 needs its WHERE clause widened to also match partially_resumed rows.

Important Files Changed

Filename	Overview
apps/sim/app/api/resume/poll/route.ts	Fixes partially_resumed rows being skipped by widening the status filter to inArray(['paused','partially_resumed']). The eligibility filter in dispatchRow correctly skips already-resuming points, but setNextResumeAt still guards on status = 'paused' only, so next_resume_at is never cleared for dispatched partially_resumed rows — they re-enter every cron batch until execution finishes.

Sequence Diagram

sequenceDiagram
    participant Cron as Cron Poll
    participant DB as pausedExecutions
    participant HITL as PauseResumeManager

    Note over DB: wait1 fires, row becomes partially_resumed
    Cron->>DB: "SELECT WHERE status IN ('paused','partially_resumed') AND next_resume_at <= now"
    DB-->>Cron: row (partially_resumed, elapsed next_resume_at)
    Cron->>HITL: enqueueOrStartResume(wait2 contextId)
    HITL->>DB: "UPDATE resumeStatus='resuming', INSERT resumeQueue"
    HITL-->>Cron: "status='starting'"
    Cron->>HITL: setNextResumeAt(null)
    Note over HITL: WHERE status='paused' guard - no-op for partially_resumed!
    Note over DB: next_resume_at remains elapsed (BUG)
    Note over Cron,DB: Next cron tick
    Cron->>DB: SELECT - same row matches again
    DB-->>Cron: row returned (no eligible points to dispatch)
    Note over Cron: dispatched=0, batch slot wasted every tick until execution completes

Loading

Comments Outside Diff (1)

1. apps/sim/app/api/resume/poll/route.ts, line 172-175 (link)

   setNextResumeAt silently no-ops for partially_resumed rows, causing permanent poll spam

   After a partially_resumed row is dispatched, setNextResumeAt (line 1707 of human-in-the-loop-manager.ts) applies a WHERE status = 'paused' guard — so the call is a no-op for partially_resumed rows. The elapsed next_resume_at is never cleared, and on every subsequent cron tick the row still satisfies the inArray(status, ['paused','partially_resumed']) AND next_resume_at <= now predicate. Each tick calls dispatchRow, finds eligiblePoints = [] (the point already moved to resuming), dispatches nothing, then calls setNextResumeAt(null) which is again a no-op. The row burns a slot in POLL_BATCH_LIMIT on every tick until the execution fully completes — starving genuinely new paused rows if many such rows accumulate.

   The guard in setNextResumeAt should include partially_resumed alongside paused so next_resume_at is properly nulled after dispatch.

_{Reviews (1): Last reviewed commit: "fix(wait): poll partially_resumed rows s..." | Re-trigger Greptile}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit ab96907. Configure here.}

[cursor]

setNextResumeAt guard misses partially_resumed rows

Medium Severity

setNextResumeAt contains a WHERE status = 'paused' guard that silently skips updates for partially_resumed rows. Since the cron poll now fetches both paused and partially_resumed rows, the post-dispatch call to setNextResumeAt in dispatchRow does nothing for partially_resumed rows. Their nextResumeAt stays at the old elapsed value, so every subsequent cron tick re-fetches them, hits an empty duePoints list (all already-dispatched points have resumeStatus beyond 'paused'), does no useful work, and still can't clear the timestamp — creating an infinite no-op scan loop until the execution fully resolves.

 

^{Reviewed by Cursor Bugbot for commit ab96907. Configure here.}