Skip to content

refactor(renderer): drop the isWorkflowRunning prop the views never read - #7040

Merged
waleedlatif1 merged 1 commit into
stagingfrom
fix-dead-isworkflowrunning-prop
Aug 24, 2026
Merged

refactor(renderer): drop the isWorkflowRunning prop the views never read#7040
waleedlatif1 merged 1 commit into
stagingfrom
fix-dead-isworkflowrunning-prop

Conversation

@waleedlatif1

Copy link
Copy Markdown
Collaborator

Follow-up to #7037, which merged before this landed. In that PR I removed only the unused binding and kept the prop — that was half a fix, and the reasoning behind it was wrong.

What I got wrong in #7037

I justified keeping the prop as "implementing it is a UX decision." That conflated two things:

  • Should the toolbar pin open during a run? — a UX decision
  • Should we keep a prop that does nothing? — not a UX decision, just dead code

Keeping it on the chance someone wants the behavior later is speculative generality. If the toolbar should pin open during a run, that gets implemented deliberately and the prop comes back with logic behind it.

What was actually dead

WorkflowBlockView and SubflowNodeView both declared isWorkflowRunning?: boolean, both had it destructured, and neither ever read it. Its TSDoc claimed it "holds every block's action swell open" — a behavior that does not exist in either view.

Both are removed, along with the two call sites that fed them.

What deliberately stays

The store subscription is not removed. workflow-block.tsx:642 and subflow-node.tsx:47 each pass the same value to two places:

Consumer Reads it?
WorkflowBlockView / SubflowNodeView no — removed here
ActionBar yes — 28 reads

ActionBar is what the surrounding TSDoc is actually describing when it says the flag "only swaps Run for Stop and disables mutations." workflow-edge-view uses it as well (7 reads) and is untouched.

So the subscription earns its keep; only the dead second pass goes.

A note on the test

workflow-block-view-interaction.test.tsx passed the flag in two cases to stage a workflow run. Since the view ignored it, those two cases were never exercising the run state their names describe — they pass on other logic. The argument is removed; the assertions are unchanged and still pass. Worth flagging for whoever owns that behavior.

Verification

  • All 26 workspaces type-check — this is what caught my first attempt, which deleted the prop while two callers and a test still passed it
  • bun run lint:check exits 0
  • 113 renderer tests, 636 across app/workspace/w and stores/workflows
  • Remaining isWorkflowRunning references are exactly the live ones: action-bar.tsx, workflow-edge-view.tsx, note-block.tsx, and the two subscriptions

Net −22 lines.

Removing only the unused binding and keeping the prop was half a fix. The views
declared it, the app passed it, and nothing read it — so the prop was dead, and
dead code does not become live by being documented.

Its TSDoc claimed it "holds every block's action swell open". That behavior does
not exist in either view. Keeping the prop on the chance someone wants it later
is the speculative-generality smell: if the toolbar should pin open during a run,
that gets implemented deliberately and the prop comes back with logic behind it.

Removed from both view interfaces and from both call sites. The store
subscription stays — `workflow-block.tsx` and `subflow-node.tsx` each passed the
same value twice, once to the dead view prop and once to `ActionBar`, which has
28 real reads and is what the surrounding TSDoc is actually describing when it
says the flag "only swaps Run for Stop and disables mutations". `workflow-edge-view`
uses it too and is untouched.

The renderer test that passed it loses the argument. Worth noting it set the flag
to stage a workflow run, and since the view ignored it those two cases were never
exercising the run state they name.
@vercel

vercel Bot commented Aug 24, 2026

Copy link
Copy Markdown

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

Project Deployment Actions Updated (UTC)
docs Ready Ready Preview Aug 24, 2026 7:03pm

Request Review

@cursor

cursor Bot commented Aug 24, 2026

Copy link
Copy Markdown

PR Summary

Low Risk
Dead prop removal with no behavior change in the views; workflow-run UI remains on ActionBar and untouched edge code.

Overview
Removes the isWorkflowRunning prop from WorkflowBlockView and SubflowNodeView, along with the misleading TSDoc that claimed it pinned every block’s action swell during a run — neither view ever read the flag.

workflow-block.tsx and subflow-node.tsx no longer forward it into those views. The execution-store subscription stays: isWorkflowRunning is still passed to ActionBar (and other live consumers like edges), where it actually drives Run/Stop and disabled mutations.

Interaction tests drop the unused fifth argument from createView; assertions are unchanged because toolbar pinning was already keyed off isRunning / selection, not workflow-wide execution.

Reviewed by Cursor Bugbot for commit 793e483. Configure here.

@greptile-apps

greptile-apps Bot commented Aug 24, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

Removes the unused isWorkflowRunning prop from workflow-block and subflow renderer views without changing live execution behavior.

  • Removes the prop from both exported view interfaces and application call sites.
  • Simplifies the workflow-block interaction-test helper and callers.
  • Preserves the execution-state subscriptions and propagation to ActionBar.

Confidence Score: 5/5

The PR appears safe to merge because it removes only unused renderer-view plumbing while preserving all live execution-state consumers.

The affected views never read the removed property, all in-repository callers were updated, and execution state continues to reach ActionBar and the untouched edge renderer.

Important Files Changed

Filename Overview
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/subflows/subflow-node.tsx Stops forwarding execution state to a subflow view that did not consume it while preserving the live ActionBar binding.
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/workflow-block/workflow-block.tsx Stops forwarding the unused prop to WorkflowBlockView while retaining execution-state use by ActionBar.
packages/workflow-renderer/src/subflow/subflow-node-view.tsx Removes an optional, unread property and its misleading documentation from the subflow view contract.
packages/workflow-renderer/src/workflow-block/workflow-block-view-interaction.test.tsx Removes the ineffective workflow-running argument from the test helper and two callers without altering tested behavior.
packages/workflow-renderer/src/workflow-block/workflow-block-view.tsx Removes an optional, unread property and its misleading documentation from the workflow-block view contract.

Reviews (1): Last reviewed commit: "refactor(renderer): drop the isWorkflowR..." | Re-trigger Greptile

@waleedlatif1
waleedlatif1 merged commit 6d313a4 into staging Aug 24, 2026
30 checks passed
@waleedlatif1
waleedlatif1 deleted the fix-dead-isworkflowrunning-prop branch August 24, 2026 19:04
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