run-llama/workflows-py
1
0
Fork 0
mirror of https://github.com/run-llama/workflows-py.git synced 2026-07-21 04:05:25 -04:00
Code Issues 18 Packages Projects Releases 10 Wiki Activity

[PR #340] [MERGED] Fix concurrent step cancellation regression in 2.14.0 #341

New Issue
Closed
opened 2026-02-16 02:17:17 -05:00 by yindo · 0 comments
yindo commented 2026-02-16 02:17:17 -05:00
Owner
Copy Link
Copy Source

📋 Pull Request Information

Original PR: https://github.com/run-llama/workflows-py/pull/340
Author: @adrianlyjak
Created: 2/6/2026
Status: ✅ Merged
Merged: 2/6/2026
Merged by: @adrianlyjak

Base: main ← Head: claude/slack-fix-concurrent-step-cancellation-QQVCu

📝 Commits (5)

  • 1cd39d1 Add xfailing test for concurrent step cancellation regression in 2.14.0
  • e8e5450 Fix concurrent step cancellation regression in 2.14.0
  • 612fbad Add patch changeset for concurrent step cancellation fix
  • e748d92 fix lint
  • 9bd2037 Improve StopEvent cancellation speed for sibling steps

📊 Changes

4 files changed (+99 additions, -6 deletions)

View changed files

➕ .changeset/fix-concurrent-step-cancellation.md (+5 -0)
📝 packages/llama-index-workflows/src/workflows/runtime/control_loop.py (+13 -3)
📝 packages/llama-index-workflows/src/workflows/runtime/types/plugin.py (+3 -3)
📝 packages/llama-index-workflows/tests/test_workflow.py (+78 -0)

📄 Description

Summary

Fixes #339

The 2.14.0 refactor from asyncio.Queue to tick_buffer + wait_for_next_task changed cancellation timing so that a StopEvent returned by one step no longer cancelled sibling concurrent steps before they could write to the event stream or have their results processed. This widened the window where a race between a StopEvent and a concurrent step's stream write could occur — races are still theoretically possible due to concurrency, but in 2.14.0 even a single asyncio.sleep(0) yield was enough for the write to slip through, whereas previously it was not.

This PR fixes the regression by eagerly cancelling worker tasks when a StopEvent is detected:

  • When a worker returns a StopEvent, immediately call cleanup_tasks() to cancel siblings before buffering the tick result
  • When CommandCompleteRun is processed, call cleanup_tasks() to ensure all workers are stopped before returning

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/run-llama/workflows-py/pull/340 **Author:** [@adrianlyjak](https://github.com/adrianlyjak) **Created:** 2/6/2026 **Status:** ✅ Merged **Merged:** 2/6/2026 **Merged by:** [@adrianlyjak](https://github.com/adrianlyjak) **Base:** `main` ← **Head:** `claude/slack-fix-concurrent-step-cancellation-QQVCu` --- ### 📝 Commits (5) - [`1cd39d1`](https://github.com/run-llama/workflows-py/commit/1cd39d1bca68fed8c47fb498a12b31020e5956b2) Add xfailing test for concurrent step cancellation regression in 2.14.0 - [`e8e5450`](https://github.com/run-llama/workflows-py/commit/e8e545060138eb82d5154f65f57aeca43752ce2d) Fix concurrent step cancellation regression in 2.14.0 - [`612fbad`](https://github.com/run-llama/workflows-py/commit/612fbadc74b61229f416017302329e3cd910e0cf) Add patch changeset for concurrent step cancellation fix - [`e748d92`](https://github.com/run-llama/workflows-py/commit/e748d926c1c7f1709316dc889526e874f5d3575f) fix lint - [`9bd2037`](https://github.com/run-llama/workflows-py/commit/9bd2037095a23f3e17327ac2c7f835765f04ea1f) Improve StopEvent cancellation speed for sibling steps ### 📊 Changes **4 files changed** (+99 additions, -6 deletions) <details> <summary>View changed files</summary> ➕ `.changeset/fix-concurrent-step-cancellation.md` (+5 -0) 📝 `packages/llama-index-workflows/src/workflows/runtime/control_loop.py` (+13 -3) 📝 `packages/llama-index-workflows/src/workflows/runtime/types/plugin.py` (+3 -3) 📝 `packages/llama-index-workflows/tests/test_workflow.py` (+78 -0) </details> ### 📄 Description ## Summary Fixes #339 The 2.14.0 refactor from `asyncio.Queue` to `tick_buffer` + `wait_for_next_task` changed cancellation timing so that a `StopEvent` returned by one step no longer cancelled sibling concurrent steps before they could write to the event stream or have their results processed. This widened the window where a race between a `StopEvent` and a concurrent step's stream write could occur — races are still theoretically possible due to concurrency, but in 2.14.0 even a single `asyncio.sleep(0)` yield was enough for the write to slip through, whereas previously it was not. This PR fixes the regression by eagerly cancelling worker tasks when a `StopEvent` is detected: - When a worker returns a `StopEvent`, immediately call `cleanup_tasks()` to cancel siblings before buffering the tick result - When `CommandCompleteRun` is processed, call `cleanup_tasks()` to ensure all workers are stopped before returning --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
yindo added the pull-request label 2026-02-16 02:17:17 -05:00
yindo closed this issue 2026-02-16 02:17:17 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
enhancement
enhancement
good first issue
pull-request
Mirrored from GitHub Pull Request
 question
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: run-llama/workflows-py#341
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?