fix(cancel-workflow-exec): move cancellation tracking for multi-task envs to redis

[icecrasher321]

Summary

Move cancellation checking to redis for multi-task envs.

Type of Change

• Bug fix

Testing

Tested manually

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	Review	Updated (UTC)
docs	Skipped		Dec 24, 2025 7:47pm

[greptile-apps]

Greptile Summary

This PR addresses a critical limitation in multi-task workflow environments by moving cancellation tracking from local AbortController signals to Redis-based shared state.

Key Changes

• New cancellation module (cancellation.ts) provides Redis-based cancellation tracking with automatic fallback when Redis is unavailable
• API endpoint added for explicit cancellation requests from clients (/cancel/route.ts)
• Execution engine refactored to poll Redis for cancellation status every 500ms, maintaining backward compatibility with abort signals
• Wait handler enhanced to check Redis during sleep intervals, enabling cancellation of long-running waits across distributed tasks
• Loop orchestrator updated to check Redis before each iteration
• Client hook now calls cancellation API endpoint in addition to aborting the fetch stream

Architecture

The implementation uses a hybrid approach:

• With Redis: Cancellation flags stored with 60-minute TTL, polled at 500ms intervals
• Without Redis: Falls back to existing AbortController.abort() signal checking
• Multi-layer detection: Engine main loop, wait blocks, and loop iterations all check cancellation status

Minor Issues

• Empty catch block in wait handler interval could mask persistent Redis errors (though cleanup still works correctly)
• clearExecutionCancellation function exists but is never called, meaning flags persist for 60 minutes even after execution completes

Confidence Score: 4/5

• This PR is safe to merge with minor improvements recommended
• The implementation is solid with proper fallback handling, rate limiting, and backward compatibility. The architecture correctly addresses the multi-task cancellation problem. Score reduced by 1 for two minor issues: empty catch block in wait handler that could mask errors, and unused cleanup function that should be integrated to prevent stale Redis flags.
• Pay attention to apps/sim/executor/handlers/wait/wait-handler.ts for the empty catch block, and consider integrating clearExecutionCancellation in the execute route

Important Files Changed

Filename	Overview
apps/sim/lib/execution/cancellation.ts	New module providing Redis-based cancellation tracking with proper fallback handling. Unused cleanup function should be integrated.
apps/sim/executor/execution/engine.ts	Refactored to use Redis cancellation checks with rate limiting (500ms interval). Maintains backward compatibility with abort signals.
apps/sim/executor/handlers/wait/wait-handler.ts	Enhanced sleep function to poll Redis for cancellation during waits. Minor issue with empty catch block in interval.

Sequence Diagram

sequenceDiagram
    participant Client as Client Hook
    participant API as Execute Route
    participant Redis as Redis
    participant Engine as Execution Engine
    participant LoopOrch as Loop Orchestrator
    participant WaitHandler as Wait Handler

    Note over Client,WaitHandler: Normal Execution Flow
    Client->>API: POST workflows execute
    API->>API: Generate executionId
    API->>Engine: Start execution with abortController
    Engine->>Engine: Initialize useRedisCancellation flag
    
    alt Has Loop Execution
        Engine->>LoopOrch: Execute iteration
        LoopOrch->>Redis: isExecutionCancelled
        Redis-->>LoopOrch: false
        LoopOrch->>Engine: Continue iteration
    end
    
    alt Has Wait Block
        Engine->>WaitHandler: Execute wait block
        WaitHandler->>WaitHandler: Start sleep with 500ms interval
        WaitHandler->>Redis: isExecutionCancelled
        Redis-->>WaitHandler: false
        WaitHandler-->>Engine: Wait completed
    end

    Note over Client,WaitHandler: Cancellation Flow
    Client->>Client: User clicks cancel
    Client->>API: POST cancel execution
    API->>Redis: markExecutionCancelled
    Redis-->>API: Success
    API-->>Client: success true
    
    Client->>API: AbortController abort
    API->>API: Stream cancel callback
    API->>Redis: markExecutionCancelled
    API->>API: abortController abort

    Note over Engine,WaitHandler: Engine Detects Cancellation
    alt Engine Main Loop Check
        Engine->>Engine: checkCancellation 500ms throttle
        Engine->>Redis: isExecutionCancelled
        Redis-->>Engine: true
        Engine->>Engine: Set cancelledFlag true
        Engine-->>API: status cancelled
    end
    
    alt During Wait Block
        WaitHandler->>Redis: isExecutionCancelled
        Redis-->>WaitHandler: true
        WaitHandler->>WaitHandler: cleanup and resolve false
        WaitHandler-->>Engine: status cancelled
    end
    
    alt During Loop Iteration
        LoopOrch->>Redis: isExecutionCancelled
        Redis-->>LoopOrch: true
        LoopOrch-->>Engine: Exit loop result
    end

    API->>Client: SSE event execution cancelled
    
    Note over Client,WaitHandler: Fallback Without Redis
    alt No Redis Available
        Client->>API: AbortController abort
        API->>API: abortController abort
        Engine->>Engine: Check abortSignal aborted
        Engine->>Engine: Set cancelledFlag true
        Engine-->>API: status cancelled
    end

Loading

[greptile-apps]

_{7 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}