Skip to content
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

dep_manager.get_result() should not be discouraged if MRunner is also used #455

Open
billhunekepf opened this issue May 11, 2023 · 1 comment

Comments

@billhunekepf
Copy link

billhunekepf commented May 11, 2023

This section of the documentation recommends using the dep_manager global to access task results in cases where you want to build a task group based on the outcome of another task (ie delayed task creation).

In my case, I attempted to use this in combination with parallel running. Unfortunately, I wasted a lot of time before realizing that the dep manager is not synchronized between task runner sub processes and that, even though a dep task has indeed finished running, its results will not be accessible via the dep manager global.

The symptom for this problem is that you will see frequent messages of Exception: taskid 'some_task_name' has no computed value! which go away if you run doit a second time (since now the result is written to disk and accessible to all sub processes)

  • The above problem applies for delayed task creation and also (of course) if you try to access task results directly, using dep_manager global, even if you've setup task_dep correctly
  • The problem appears to not apply in cases where get_args is used to indicate that task results are needed by dependent tasks. Unfortunately, get_args is of no help for the use case of trying to do delayed task building
Fund with Polar
@schettino72
Copy link
Member

realizing that the dep manager is not synchronized between task runner sub processes and that, even though a dep task has indeed finished running, its results will not be accessible via the dep manager global.

I think your conclusion is incorrect (or at least should be). do you have an example to show this behaviour?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants