Skip to content

improvement(snapshot): exclude sentinel in client side activation detection#3432

Merged
icecrasher321 merged 1 commit intostagingfrom
improvement/snapshot-highlight
Mar 6, 2026
Merged

improvement(snapshot): exclude sentinel in client side activation detection#3432
icecrasher321 merged 1 commit intostagingfrom
improvement/snapshot-highlight

Conversation

@icecrasher321
Copy link
Collaborator

Summary

Exclude sentinel handling [code cleanup]

Type of Change

  • Other: Code cleanup

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
Copy link

vercel bot commented Mar 6, 2026

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

1 Skipped Deployment
Project Deployment Actions Updated (UTC)
docs Skipped Skipped Mar 6, 2026 1:20am

Request Review

@cursor
Copy link

cursor bot commented Mar 6, 2026

PR Summary

Low Risk
Low risk UI-state change that only affects how outgoing edges are marked success vs error on the client; potential impact is incorrect edge highlighting if the new status rules don’t match server behavior.

Overview
Adjusts client-side edge run-status marking to better reflect execution failures.

markOutgoingEdgesFromOutput now marks any activated outgoing edge as error when the block output contains an error (not just when the handle is error), and removes the special-case that always marked no-handle edges as success. Sentinel handle cases were also removed from the client activation switch to simplify the mapping.

Written by Cursor Bugbot for commit 0a06807. Configure here.

@greptile-apps
Copy link
Contributor

greptile-apps bot commented Mar 6, 2026

Greptile Summary

This PR performs a focused cleanup of the client-side edge activation utility (workflow-execution-utils.ts), removing sentinel control-flow handles from shouldActivateEdgeClient and fixing edge-status computation in markOutgoingEdgesFromOutput to correctly reflect block error state.

Key changes:

  • Removed sentinel handle cases (loop_exit, loop_continue, loop_continue_alt, parallel_exit) from the switch in shouldActivateEdgeClient. These cases all returned true, identical to the existing default branch, so this is a pure dead-code removal. Notably, loop_continue_alt was already a bug — the constant EDGE.LOOP_CONTINUE_ALT resolves to 'loop-continue-source' (hyphens), not 'loop_continue_alt' (underscores), so that case never matched at runtime.
  • Removed null-handle early return: Previously, edges without a sourceHandle were unconditionally set to 'success'. Now they flow through shouldActivateEdgeClient (which still returns true for null handles) and are correctly assigned 'error' status when output?.error is set (e.g., during block:error events).
  • Improved status expression: Changed handle === 'error' ? 'error' : 'success' to handle === 'error' ? 'error' : output?.error ? 'error' : 'success', so that non-error-handle edges activated during an errored block execution are correctly shown as 'error' in the UI rather than 'success'.

Confidence Score: 4/5

  • This PR is safe to merge — changes are limited to client-side visual state, with no impact on execution logic.
  • The diff is small and focused. The sentinel case removal is provably a no-op (all removed cases returned true, same as default). The null-handle and status-expression changes improve correctness by aligning visual edge state with actual block error state. The change is confined to client-side UI feedback; the authoritative server-side executor logic in EdgeManager is untouched.
  • No files require special attention.

Important Files Changed

Filename Overview
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/utils/workflow-execution-utils.ts Removes dead sentinel handle cases from shouldActivateEdgeClient (they all fell to default: return true), drops the null-handle early return in markOutgoingEdgesFromOutput, and improves edge status logic to correctly reflect error state for non-error-handle edges. Behavioral changes are intentional and appear correct.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["markOutgoingEdgesFromOutput(blockId, output, ...)"] --> B["Filter edges by source === blockId"]
    B --> C["For each outgoing edge"]
    C --> D["shouldActivateEdgeClient(handle, output)"]

    D --> E{handle?}
    E -- "null / undefined" --> F["return true"]
    E -- "condition-*" --> G["output.selectedOption === conditionValue?"]
    E -- "router-*" --> H["output.selectedRoute === routeId?"]
    E -- "'error'" --> I["return !!output.error"]
    E -- "'source'" --> J["return !output.error"]
    E -- "loop/parallel or default" --> K["return true (default)"]

    F --> L{shouldActivate?}
    G --> L
    H --> L
    I --> L
    J --> L
    K --> L

    L -- "false" --> M["Skip — edge not activated"]
    L -- "true" --> N["Compute status"]

    N --> O{"handle === 'error'?"}
    O -- "yes" --> P["status = 'error'"]
    O -- "no" --> Q{"output?.error?"}
    Q -- "yes" --> R["status = 'error'"]
    Q -- "no" --> S["status = 'success'"]

    P --> T["setEdgeRunStatus(...)"]
    R --> T
    S --> T
Loading

Last reviewed commit: 0a06807

@icecrasher321 icecrasher321 merged commit 4f45f70 into staging Mar 6, 2026
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant