I tried running a basic workflow of Quality Control and Mapping for RNAseq, with Cutadapt, RNA star and HTseq, with FASTQC/MULTIQC and qualimap. But everytime I try to run it, it gives me this error and Cutadapt does not run
This feature is somewhat new, a new release of Galaxy itself is pending, and this may be related to prior known but soon-to-be-fixed issues when Galaxy upgrades. I would also suggest reviewing the work that completed already – were the inputs intact (contain successful, non-empty, content)?
If that fails again (is reproducible, with upstream data confirmed), we can followup more from there. My guess would be that there is a problem within the workflow itself – are you really inputting two different collection types into the same tool at the same step? That probably won’t work for a few reasons. But we can review the details after the rerun/data check.
After rechecking, it seems like cutadapt is somehow the problem. I can run it, with the same configurations, without using workflow. But when I use the workflow, it always fails.
One important point is that every time I try do edit my workflow, the connection between the paired list and cutadapt disapears.
Another example, I just tried to run this and it couldn’t feed the paired list to cutadapt. When I open it to edit, cutadapt always disconnect from the list:paired input, even though I can run it without the workflow (with same configs)
Thanks for the screenshots. I had forgotten that there are some known issues with
Cutadapt and paired-end collections when used in workflows that have not been resolved yet (to my knowledge, did start a test just now to check, still scheduling/running).
fastp are commonly used alternatives that both function with this type of input within a workflow. You may need to use one of those instead.
This is the part of your screenshot that explains what problem came up before that prior issue would manifest. And knowing how to address it will apply to many other use cases.
Summary: Workflows contain metadata about the relationships between inputs, tools, and tool output (which are often inputs to downstream tools). When the workflow’s internal metadata doesn’t match up, the solution is to disconnect all of the workflow’s “noodles” then reconnect them.
Start with the initial “inputs” and connect to downstream tools in the order of execution (“left to right” within the editor).
In our test, connecting a paired-end collection list wasn’t a problem, so you should be able to get that far following the advice above. Then try to run the workflow. If
Cutadapt fails or stalls again, then you’ll need to pick a different trimming tool.
It is known that the “disconnect/reconnect” usage is not ideal … but also that it is required for now. This tends to show up when new inputs or adjusted input types are added to existing workflows.
Your problem is a bit more complicated since it involves adjusting the workflow AND it still might fail given the prior known issues with
Cutadapt. But you can certainly try the workflow metadata reset, rerun, and see what happens before deciding to incorporate a different read trimmer tool.
Hope that helps with some options to get this going. Even if
Cutadapt needs more changes, and that is prioritized, the updated tool wouldn’t be immediately available. This has been an open issue for over a year, isn’t a simple fix, and there are functional alternative tools available.
Turns out that
Cutadapt is working fine in a workflow now. Based on that result, reconnecting the workflow “noodles” will likely solve your entire issue as well. Make sure you are incorporating the most current tool version (all steps/tools) to avoid older-but-fixed problems.
Test history and workflow if you want to compare your work to our test. I’ll leave this shared for a while, may help others, too.
Reconnecting the noodles until it works, although inefficient, it does work! Thank you