PR Summary

Medium Risk
Touches pause/resume orchestration and DB transaction boundaries; mistakes could cause duplicate/queued resumes to be mishandled or add latency via retries, but changes are scoped and covered by new unit tests.

Overview
Fixes the pause→resume race condition by wrapping persistPauseResult in a single DB transaction that both upserts the pausedExecutions row and (if present) claims the oldest pending resumeQueue entry while marking the pause point as resuming, then drains queued resumes after commit.

Adds exponential-backoff retry to enqueueOrStartResume (5 attempts starting at 50ms) only for the specific "Paused execution not found or already resumed" transient case, refactoring the original logic into tryEnqueueOrStartResume, and introduces a new Vitest suite covering success-after-retry, exhaustion, no-retry for other errors, and immediate success.

^{Written by Cursor Bugbot for commit 1e4b3e0. This will update automatically on new commits. Configure here.}

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

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Mar 9, 2026 8:07am

Greptile Summary

This PR fixes a pause-resume race condition (#3081) in PauseResumeManager where a resume request arriving before persistPauseResult commits its DB insert would fail with "Paused execution not found". Two complementary mechanisms are introduced:

• Transaction wrapping in persistPauseResult: The pause record insert and any pending resume queue drain are now performed atomically. Once committed, a concurrent SELECT FOR UPDATE in enqueueOrStartResume will block on the row lock rather than see a missing row.
• Exponential-backoff retry in enqueueOrStartResume: A new tryEnqueueOrStartResume helper carries the original logic; the public method wraps it in up to 5 attempts (50 ms base, doubling each time) and retries only the specific "not found" error, letting all other errors propagate immediately.

Key observations:

• The retry guard uses exact string comparison (error.message === 'Paused execution not found or already resumed') to identify the race-condition error. This works today but is fragile; a typed error class would make the relationship between throw and catch explicit and refactor-safe.
• The JSDoc on RESUME_RETRY_BASE_DELAY_MS lists five delay values (50 → 800 ms) but only four delays occur in practice — the final attempt re-throws immediately without waiting.
• The test helper emptyTerminal is declared but never referenced; it is dead code that will likely trigger a lint warning.
• Four unit tests adequately cover the retry success path, exhaustion path, non-retriable errors, and the happy (no-retry) path.

Confidence Score: 4/5

• Safe to merge; the two-pronged fix is logically sound and well-tested, with only minor style concerns.
• The transaction wrapping and retry logic correctly address the described race condition. Error handling is selective (only the race-condition error is retried). The four unit tests validate the critical paths. The only concerns are code quality issues (fragile string comparison, a stale comment, and unused test helper) that do not affect runtime correctness.
• No files require special attention beyond the minor style issues noted in human-in-the-loop-manager.ts and human-in-the-loop-manager.test.ts.

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant Exec as Workflow Executor
    participant PRM as PauseResumeManager
    participant DB as Database (PostgreSQL)
    participant API as Resume API

    Exec->>PRM: persistPauseResult(...)
    PRM->>DB: BEGIN TRANSACTION
    PRM->>DB: INSERT pausedExecutions (row locked until commit)
    PRM->>DB: SELECT pending resumeQueue entries
    alt pending entry found (queued before commit)
        PRM->>DB: UPDATE resumeQueue → 'claimed'
        PRM->>DB: UPDATE pausedExecutions.pausePoints → 'resuming'
    end
    PRM->>DB: COMMIT (row now visible)
    PRM->>PRM: processQueuedResumes(executionId)

    note over API,DB: Race: resume arrives before COMMIT

    API->>PRM: enqueueOrStartResume(...)
    loop Retry (up to 5 attempts, 50ms×2^n backoff)
        PRM->>DB: BEGIN TRANSACTION
        PRM->>DB: SELECT FOR UPDATE pausedExecutions WHERE executionId=?
        alt row not yet visible (pre-commit race window)
            DB-->>PRM: empty result
            PRM-->>PRM: throw "Paused execution not found"
            PRM->>PRM: wait delay, retry
        else row visible and locked
            DB-->>PRM: row (blocks if persistPauseResult tx still open)
            PRM->>DB: INSERT resumeQueue → 'claimed'
            PRM->>DB: UPDATE pausedExecutions.pausePoints → 'resuming'
            PRM->>DB: COMMIT
            PRM-->>API: { status: 'starting', resumeExecutionId }
        end
    end

_{Last reviewed commit: 1e4b3e0}