Skip to content

Fix/ Several steps waiting at the same lock, handler only released on… #18470

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

CodeDecree
Copy link
Contributor

Description

So on investigation I found out that if stepwise is set to true, the execution goes under the _step_condition lock that is shared by every task. That lock is released by the handler via _step_condition.notify() in handler.py.

Now, if a step execution outputs an event that triggers more than one step/task, every task halts sharing the same lock, but the handler only releases one using notify(). And if there were multiple tasks waiting to be executed, only one of them executes.

Fix: I changed _step_condition.notify() to _step_condition.notify_all() so all the waiting tasks at that step get their execution.

Fixes #18334

New Package?

Did I fill in the tool.llamahub section in the pyproject.toml and provide a detailed README.md for my new integration or package?

  • Yes
  • No

Version Bump?

Did I bump the version in the pyproject.toml file of the package I am updating? (Except for the llama-index-core package)

  • Yes
  • No

Type of Change

Please delete options that are not relevant.

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

How Has This Been Tested?

Your pull-request will likely not be merged unless it is covered by some form of impactful unit testing.

  • I added new unit tests to cover this change
  • I believe this change is already covered by existing unit tests

Suggested Checklist:

  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • I have added Google Colab support for the newly added notebooks.
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • I ran make format; make lint to appease the lint gods

Sorry, something went wrong.

…e step with notify(). Replaced with notify_all() to release lock for all waiting steps.
@dosubot dosubot bot added the size:XS This PR changes 0-9 lines, ignoring generated files. label Apr 16, 2025
@logan-markewich
Copy link
Collaborator

logan-markewich commented Apr 16, 2025

@CodeDecree doesn't this break the concept of stepwise execution? If multiple steps are waiting to run, they should run one at a time right?

(being completely honest, this feature has been a bit of a nightmare to implement/maintain, and I lean heavily towards ripping it out -- curious if you had an actual use-case for this?)

@CodeDecree
Copy link
Contributor Author

@logan-markewich Ah, yes, you are right. If one step triggers multiple tasks, then all those will go concurrently.

Maybe we can call _step_condition.notify() an equal number of times to the len(await self.ctx.running_steps()) in the handler but I do believe it might have its own repercussions. I can try to fix that and probably add the test cases for the same.

I never used this feature myself. I was just going through the repo, exploring some issues, trying to contribute. Anyways, 'ripping it out' sounds like a pretty cool PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
size:XS This PR changes 0-9 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug]: A Workflow runs properly when .run(), but not when .run(stepwise=True)
2 participants