refactor(renderer): drop the isWorkflowRunning prop the views never read - #7040
Conversation
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.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
PR SummaryLow Risk Overview
Interaction tests drop the unused fifth argument from Reviewed by Cursor Bugbot for commit 793e483. Configure here. |
Greptile SummaryRemoves the unused
Confidence Score: 5/5The 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
|
| 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
What I got wrong in #7037
I justified keeping the prop as "implementing it is a UX decision." That conflated two things:
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
WorkflowBlockViewandSubflowNodeViewboth declaredisWorkflowRunning?: 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:642andsubflow-node.tsx:47each pass the same value to two places:WorkflowBlockView/SubflowNodeViewActionBarActionBaris what the surrounding TSDoc is actually describing when it says the flag "only swaps Run for Stop and disables mutations."workflow-edge-viewuses 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.tsxpassed 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
bun run lint:checkexits 0app/workspace/wandstores/workflowsisWorkflowRunningreferences are exactly the live ones:action-bar.tsx,workflow-edge-view.tsx,note-block.tsx, and the two subscriptionsNet −22 lines.