-
Notifications
You must be signed in to change notification settings - Fork 595
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
Defer error exit status to end of pipeline run #4446
Comments
Is it not |
No, The use case is for automated runs. If there is one bad sample out of hundreds, the run will fail early and need to wait until it can be manually restarted. Then the whole pipeline needs to run through, which is slow. With this option, the other samples would all process so when the pipeline is resumed without the bad sample it would complete very quickly. |
yeah, you are right. I was trying to be lazy 😆 |
We could either change |
I think |
Agreed. |
If you want to be fancy, we could call it |
I generally prefer verbose and clear, for me |
This is the solution that I was looking for. Is it still under consideration ? |
I would like to second @boothms message. This would greatly improve the runs with multiple samples where at least one process for one sample might fail. It would be great if the progress of the execution could continue for the rest of the healthy samples. |
@bentsherman , thank you so much for jumping on this. I have a quick question about the implementation. If one sets the Would there be a place where these 2 are not mutually exclusive? Try the maxRetries, and then if it fails, still have the possibility to defer the exit status to the end of the pipeline? |
You could do that with a closure: process.errorStrategy = { task.attempt < 3 ? 'retry' : 'ignoreThenFail' } |
This is great. Thank you once again. I'm really looking forward to testing this. |
Hi folks, I saw that the PR is almost done. Do you have an estimate on when this might be merged? |
Relevant community discussion: https://community.seqera.io/t/handling-single-sample-failures/618/3 |
This is a pretty useful feature. Imagine the scenario where you have 96 independent samples, if 1 fails and it brings the whole pipeline crashing down that's annoying, but if you use errorStrategy = 'ignore' then you have to write your own solution. We could have
process.errorStrategy = 'catch'
. This might be a separate ticket though.Having some form of introspection on tasks in the workflow.onComplete block would also help for similar reasons and be more generally useful.
Originally posted by @adamrtalbot in #4365 (comment)
The text was updated successfully, but these errors were encountered: