When I try to run a workflow where the outputs from MultiQC are set to remove tags, I get the following error message:
Invocation scheduling failed because an unexpected failure occurred.
The outputs appear in my history, but they never actually run. For context, the inputs are raw data from FastQC.
I’m running Galaxy Version 1.11+galaxy1 and the workflow can be found here.
(Sorry for any formatting oddities; I’ve never used this forum before.)
Turns out it also does this when I run workflows with other tools that are also set to remove tags from their outputs. The same thing that happened in the first workflow also happened when I ran this workflow containing Cutadapt.
Thanks for sharing the examples! Just from a 2 second review, this looks like a bug. I am doing some tests … more feedback soon.
That went quickly! I wasn’t able to reproduce the problem.
These are my test histories. Do you notice what might be different?
- running the output 3x with different initial tags Galaxy
- sending the output to a new history Galaxy
My workflow invocations are not interesting … but it sounds like yours was. Maybe share a screenshot or a link for that? Or one of the output histories (simple please!).
Thanks for the response! I’m not noticing any glaring differences between your histories and mine.
Here’s a screenshot of the error message I’ve been getting:
I’d share a history where this occurred, but I get an error message every time I post the link for some reason.
Yeah, you won’t be able to post publically the same URL repeatedly (new user).
I’ll send you a direct message, and you can post the history share link in there.
I’m also wondering if any of the input datasets themselves have some problem. Maybe check to make sure that none are empty files, and maybe test if the tool works directly on that data (outside of a workflow?) first?
I do see that those two input reports from MultiQC are hidden in your screenshot … are those OK?
Just double-checked. None of the files are empty (including the hidden ones), and MultiQC runs normally outside the workflow.
The issue has been ticketed. Please follow for the pending resolution: [23.1] Fix tag ownership check in post job action context by mvdbeek · Pull Request #16771 · galaxyproject/galaxy · GitHub
Thanks @zhenderson1 for reporting the problem with examples!
For others … the workaround solution was to mark the intermediate outputs as primary outputs in the workflow editor (while retaining hidden status). Whether that will also work for others is not known but is something to try. This issue coming up at all should be somewhat rare even now.