fix(executor): fail a stop-after run whose routing skips the stop block by waleedlatif1 · Pull Request #8635 · simstudioai/sim

waleedlatif1 · 2026-10-05T22:10:27Z

Summary

Follow-up to feat(workflows): stop a manual v2 run after a block, and workflows run --stop-after #8622. A stop-after run only stopped when the stop block completed. When a router, condition, or untaken error path routed the run away from that block, the stop never triggered. The run then finished every other branch and reported success as if it had stopped there. A check before the run can't see this.
The engine now ends the run as soon as every path into the stop block has been deactivated, before any further block starts. It fails the run with Stop block "<name>" (<id>) was not reached: no path this run took leads to it. The decision reuses the edge manager's own readiness state through the new EdgeManager.canNodeStillRun, so it is the same decision that would otherwise leave the block unqueued.
Any run that ends without completing its stop block fails the same way. That covers a stop block missing from the executed graph, and a Response block that ended the run first (the error says so). A run whose stop block is proven unreachable fails even if another branch paused, so it can't resume past the stop block.
A loop or parallel stop with nothing to run exits from its start sentinel, and its end sentinel never runs. That exit now counts as reaching the stop. Before, this case also ran the rest of the workflow.
Callers:
- CLI --stop-after and the v2 API: get status: failed with the message, and the CLI exits non-zero.
- Copilot run_workflow_until_block: returns a failed tool result with the message, where it used to return success with stoppedAfterBlockId.
- UI "run until here": shows the run error in place of a silent full run.
- run_block (entry == stop): unchanged.
The v2 contract description and the --stop-after help (plus generated OpenAPI and CLI docs) describe the failure.

Type of Change

Bug fix

Testing

executor/execution/engine.test.ts: new stop-after cases run the real DAG builder and edge manager:
- condition, router and untaken error path routing away from the stop block;
- a stop block missing from the graph;
- a Response block ending the run before the stop block;
- another branch pausing after the stop block is skipped;
- an empty loop as the stop block;
- positive controls: the stop block on the taken branch, a join with one skipped input, the entry as the stop block, and a loop stop block queued by a dead end inside the loop.
Six of these failed on the pre-fix engine. I also reverted each guard on its own (the queued flag, the early stop, the final check, the Response mark, the empty-subflow exit), and each revert turned its named test red.
scripts/test-workflow-stop-after-e2e.ts gains a condition fixture, run against a self-hosted app on a disposable Postgres:
- stop on the taken branch: completes;
- stop on the skipped branch: fails in under 2s, well before the other branch's 4s block would finish;
- the CLI exits non-zero for the same run.
The new E2E check failed on the pre-fix engine: the run came back completed. All 11 checks pass with the fix.
bun run lint, type-check, check:audits, docs-manifest:check, block-registry check: pass.
bun run test: all workspaces pass. One unrelated markdown-parser test timed out under machine load and passes when run on its own.

Checklist

Code follows project style guidelines
Self-reviewed my changes
Tests added/updated and passing (new tests pass the test-audit authoring gate)
No new warnings introduced
I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

A run with stopAfterBlockId only stopped when the stop block completed. When a router, condition, or untaken error path routed the run away from it, the stop never triggered and the run finished every other branch, reporting success as if it had stopped there. A static check before the run cannot see this. - The engine ends the run as soon as every path into the stop block has been deactivated, before any further block starts, and fails it with `Stop block "<name>" (<id>) was not reached: no path this run took leads to it`. - Any run that ends without completing its stop block fails the same way: a stop block missing from the executed graph, or a Response block that ended the run first. - A loop or parallel stop with nothing to run completes at its start sentinel, whose end sentinel never runs, so that exit now counts as reaching it. - The v2 contract and the CLI `--stop-after` help describe the failure. - E2E: a condition fixture checks the stop on the taken branch still stops there, a stop on the skipped branch fails the run before the other branch's slow block finishes, and the CLI exits non-zero.

waleedlatif1 · 2026-10-05T22:10:32Z

@greptile

waleedlatif1 · 2026-10-05T22:10:33Z

@cubic-dev-ai review this PR

vercel · 2026-10-05T22:10:33Z

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

1 Skipped Deployment

Project	Deployment	Actions	Updated
docs	Skipped		Oct 5, 2026 10:18pm UTC

cubic-dev-ai · 2026-10-05T22:10:38Z

@cubic-dev-ai review this PR

@waleedlatif1 I have started the AI code review. It will take a few minutes to complete.

cubic-dev-ai

No issues found across 9 files

Confidence score: 5/5

Automated review surfaced no issues in the provided summaries.
No files require special attention.

_{Re-trigger cubic}

cubic-dev-ai

All reported issues were addressed across 9 files

_{Fix all with cubic | Re-trigger cubic}

greptile-apps · 2026-10-05T22:15:30Z

Confidence Score: 5/5

[High risk] Changes workflow execution logic for stop-after runs.

The PR appears safe to merge; no outstanding findings remain.

Summary

The PR makes stop-after runs fail when routing makes the stop block unreachable, distinguishes runs ended first by a Response block, and updates tests and public descriptions.

The follow-up preserves a pause only while the stop block can still run.
The previous Response-message finding was fixed and its thread is resolved.

_{Reviews (2) · Last reviewed commit: "fix(executor): a skipped stop block fail..."}

…, and names a Response ending - A run whose stop block was proven unreachable fails even when another branch paused, instead of returning a paused run that would resume past it. - When a Response block ended the run first, the error says so rather than claiming no path leads to the stop block.

waleedlatif1 · 2026-10-05T22:18:48Z

@greptile

waleedlatif1 · 2026-10-05T22:18:49Z

@cubic-dev-ai review this PR

cubic-dev-ai · 2026-10-05T22:18:56Z

@cubic-dev-ai review this PR

@waleedlatif1 I have started the AI code review. It will take a few minutes to complete.

cubic-dev-ai

No issues found across 9 files

Confidence score: 5/5

Automated review surfaced no issues in the provided summaries.
No files require special attention.

_{Re-trigger cubic}

vercel Bot deployed to Preview October 5, 2026 22:12 View deployment

cubic-dev-ai Bot reviewed Oct 5, 2026

View reviewed changes

Comment thread apps/sim/executor/execution/engine.ts Outdated

greptile-apps Bot reviewed Oct 5, 2026

View reviewed changes

Comment thread apps/sim/executor/execution/engine.ts Outdated

vercel Bot temporarily deployed to Preview October 5, 2026 22:18 Inactive

cubic-dev-ai Bot reviewed Oct 5, 2026

View reviewed changes

waleedlatif1 merged commit 844d181 into staging Oct 5, 2026
25 checks passed

waleedlatif1 deleted the fix/stop-after-unreached branch October 5, 2026 22:28

waleedlatif1 mentioned this pull request Oct 6, 2026

v0.9.15: performance improvements, cli run until, memory fixes, xhigh thinking #8654

Closed

Navigation Menu

Repository navigation

fix(executor): fail a stop-after run whose routing skips the stop block - #8635

fix(executor): fail a stop-after run whose routing skips the stop block#8635
waleedlatif1 merged 2 commits into
stagingfrom
fix/stop-after-unreached

waleedlatif1 commented Oct 5, 2026 •

edited

Loading

Uh oh!

waleedlatif1 commented Oct 5, 2026

Uh oh!

waleedlatif1 commented Oct 5, 2026

Uh oh!

vercel Bot commented Oct 5, 2026 •

edited

Loading

Uh oh!

cubic-dev-ai Bot commented Oct 5, 2026

Uh oh!

cubic-dev-ai Bot left a comment

Uh oh!

cubic-dev-ai Bot left a comment •

edited

Loading

Uh oh!

Uh oh!

greptile-apps Bot commented Oct 5, 2026 •

edited

Loading

Uh oh!

Uh oh!

waleedlatif1 commented Oct 5, 2026

Uh oh!

waleedlatif1 commented Oct 5, 2026

Uh oh!

cubic-dev-ai Bot commented Oct 5, 2026

Uh oh!

cubic-dev-ai Bot left a comment

Uh oh!

Uh oh!

This branch was previously deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

waleedlatif1 commented Oct 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Type of Change

Testing

Checklist

Uh oh!

waleedlatif1 commented Oct 5, 2026

Uh oh!

waleedlatif1 commented Oct 5, 2026

Uh oh!

vercel Bot commented Oct 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cubic-dev-ai Bot commented Oct 5, 2026

Uh oh!

cubic-dev-ai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

greptile-apps Bot commented Oct 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Confidence Score: 5/5

Summary

Uh oh!

Uh oh!

waleedlatif1 commented Oct 5, 2026

Uh oh!

waleedlatif1 commented Oct 5, 2026

Uh oh!

cubic-dev-ai Bot commented Oct 5, 2026

Uh oh!

cubic-dev-ai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

This branch was previously deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

waleedlatif1 commented Oct 5, 2026 •

edited

Loading

vercel Bot commented Oct 5, 2026 •

edited

Loading

cubic-dev-ai Bot left a comment •

edited

Loading

greptile-apps Bot commented Oct 5, 2026 •

edited

Loading