fix(workflow) Fix embedded workflow logs

[TheodoreSpeaks]

Summary

Embedded workflows only show logs on block completion. Extract workflow event handling into shared util function so behavior remains the same between full and embedded workflows.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation
• Other: ___________

Testing

Validated that workflow logs are shown as soon as block is executing for both full and embedded workflow views

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)

Screenshots/Videos

[vercel]

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

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Mar 14, 2026 7:58pm

[cursor]

PR Summary

Medium Risk
Refactors client-side execution event handling and console updates, which can affect real-time workflow UI state (active blocks, edge statuses, and log entries) across multiple execution entrypoints. Risk is moderate due to behavior changes in the logging path, especially around container/subflow blocks and executionId tracking.

Overview
Fixes embedded workflow runs only showing logs on completion by extracting SSE block:* event handling into a shared createBlockEventHandlers helper and reusing it from both use-workflow-execution and executeWorkflowWithFullLogging.

The shared handlers now centralize active-block ref counting, edge run status marking, console entry add/update behavior (including block:childWorkflowStarted updates), and container block clone-id handling; executeWorkflowWithFullLogging also updates its executionIdRef from execution:started so console updates route to the correct execution.

Includes a small test mock cleanup in route.async.test.ts (dedupes AuthType mock shape).

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

[greptile-apps]

Greptile Summary

This PR fixes a bug where embedded workflow views only showed block logs after block completion. It does so by extracting the block event handler logic from use-workflow-execution.ts into a shared createBlockEventHandlers utility function and wiring executeWorkflowWithFullLogging to use it with consoleMode: 'update' and includeStartConsoleEntry: true, so an isRunning: true console entry is added immediately when a block starts and updated on completion — mirroring the behavior already present in the full workflow view.

Key changes:

• BlockEventHandlerConfig interface and all handler logic moved from the hook to workflow-execution-utils.ts as createBlockEventHandlers
• executeWorkflowWithFullLogging now delegates to createBlockEventHandlers with consoleMode: 'update' and includeStartConsoleEntry: true, fixing the log-only-on-completion bug for embedded workflows
• executionIdRef is introduced so the server-assigned execution ID is used consistently across all event handlers (including after execution:started fires)

Issues found:

• onBlockCompleteCallback errors are now silently swallowed (.catch(() => {})), removing the logger.error call that existed in the original hook — this degrades observability for callbacks used by copilot tools
• Non-empty top-level container blocks (loop/parallel) can get stuck displaying as isRunning: true in the embedded console: onBlockStarted adds the entry, but the early-return guard in onBlockCompleted skips the updateConsoleEntry call, so the entry is never marked as no longer running

Confidence Score: 3/5

• The core refactor is sound but a logic gap could leave loop/parallel block console entries stuck in a running state in the embedded view.
• The extraction of block event handlers is well-structured and the fix for showing logs on block start is correct for regular blocks. However, the early-return guard in onBlockCompleted for non-empty container blocks skips the updateConsoleEntry call, which means console entries added by onBlockStarted (with isRunning: true) are never cleared for loop/parallel blocks — a regression for the exact scenario this PR aims to fix. The silent swallowing of onBlockCompleteCallback errors is a minor but real observability loss.
• apps/sim/app/workspace/[workspaceId]/w/[workflowId]/utils/workflow-execution-utils.ts — specifically the onBlockCompleted early-return path for container blocks and the .catch(() => {}) on the block-complete callback.

Important Files Changed

Filename	Overview
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/utils/workflow-execution-utils.ts	Receives the full createBlockEventHandlers factory and the BlockEventHandlerConfig/Deps interfaces extracted from the hook. Two issues: onBlockCompleteCallback errors are now silently swallowed (.catch(() => {})), and non-empty container blocks can be left with a stuck isRunning: true console entry when consoleMode: 'update' is used.
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/hooks/use-workflow-execution.ts	Hook is correctly trimmed to delegate to createBlockEventHandlers; deps array is consistent with the new factory signature and no issues found in the hook itself.

Sequence Diagram

sequenceDiagram
    participant SSE as SSE Stream
    participant EWF as executeWorkflowWithFullLogging
    participant BEH as createBlockEventHandlers
    participant Store as Zustand Stores

    SSE->>EWF: execution:started
    EWF->>Store: setCurrentExecutionId
    EWF->>EWF: executionIdRef.current = event.executionId

    SSE->>EWF: block:started
    EWF->>BEH: onBlockStarted(data)
    BEH->>Store: updateActiveBlockRefCount (active=true)
    BEH->>Store: addConsole {isRunning: true} [includeStartConsoleEntry=true]

    SSE->>EWF: block:completed (regular block)
    EWF->>BEH: onBlockCompleted(data)
    BEH->>Store: updateActiveBlockRefCount (active=false)
    BEH->>Store: setBlockRunStatus success
    BEH->>Store: markOutgoingEdgesFromOutput
    BEH->>Store: updateConsole {isRunning: false} [consoleMode=update]

    SSE->>EWF: block:completed (container block, non-empty)
    EWF->>BEH: onBlockCompleted(data)
    BEH->>Store: updateActiveBlockRefCount (active=false)
    BEH->>Store: setBlockRunStatus success
    Note over BEH,Store: ⚠️ Early return — isRunning entry never updated

    SSE->>EWF: block:error
    EWF->>BEH: onBlockError(data)
    BEH->>Store: setBlockRunStatus error
    BEH->>Store: updateConsole {isRunning: false, error} [consoleMode=update]

    SSE->>EWF: block:childWorkflowStarted
    EWF->>BEH: onBlockChildWorkflowStarted(data)
    BEH->>Store: updateConsole {childWorkflowInstanceId}

    SSE->>EWF: execution:completed
    EWF->>Store: setCurrentExecutionId(null)

Loading

_{Last reviewed commit: 9d6a87b}

[greptile-apps]

Silent error swallowing in callback

The original use-workflow-execution.ts logged errors from onBlockCompleteCallback:

onBlockCompleteCallback(data.blockId, data.output).catch((error) => {
  logger.error('Error in onBlockComplete callback:', error)
})

The refactored version silently discards them with .catch(() => {}). Since workflow-execution-utils.ts doesn't import a logger, callback errors will be completely invisible in logs, making debugging harder when consumers like the copilot tool's onBlockComplete fail silently.

Consider either importing createLogger here and restoring the log, or surfacing the error through a dedicated error handler in BlockEventHandlerDeps.

[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.}