Workflow blocks after changing one module


I have the following workflow:

It processes paired-end atac-seq data using mm10.

This is a copy of an existing functional workflow to which I just modified trimmomatic to trim galore. I imagine that my problem is coming from this tool.

Indeed, the workflow blocks after bowtie2 and does not load all steps in the history.

My question is, is there any log file where I can see where is the problem coming from?

Is the only way to solve the problem to rebuild the entire thing step by step?



1 Like

Welcome, @descostes!

The server/shared link is not publically accessible, so we can’t help to review the problem in detail.

I can let you know that certain earlier versions of Trimmomatic didn’t work well in workflows for some use cases. Changes included in recent Galaxy releases (most current version is 19.01) and to the Trimmomatic tool itself (most current version 0.36.6) resolved those issues.

I would suggest contacting the administrators of that server to make sure Galaxy/Trimmomatic are at the most current versions, then modify the workflow to include that updated version of Trimmomatic. If that doesn’t resolve the problem, then also ask them to update the other tools included your workflow (including Bowtie2), if not at the most current version available in the ToolShed, to eliminate other potential technical issues as being a factor.

Other items to note:

  • Workflows populate output datasets into the history in the order of execution. This effectively means that not all steps will appear at the very start, but will show up as the processing proceeds over time. Now, this is somewhat dependent on the server resources, the tools invoked, and whether or not dataset collections are included. So might want to check your history now and see if more content has populated since you first wrote in.

  • You could also ask the administrators if the server is busy, causing a delay at the mapping step with Bowtie2. This is a computationally intensive tool and usually takes longer to execute than Trimmomatic.

  • There is a known issue regarding “input” changes and workflow execution. The issue ticket is here, and you could try the workaround steps if you think this might be a factor:

  • We are working to resolve the issue above and discussing ways to make workflow execution issues/conflicts clearer for ends users to aid with troubleshooting, directly in the interface, with priority.

Final option:

  • Test at the public server Galaxy Main to compare results.

  • Download/import the workflow, update tool versions (as needed), create a history with sample input data, and test it out to see what results. You might need to edit the workflow to remove any tools not available at this server (likely to be downstream of Trimmomatic/Bowtie2).

  • If it works at Galaxy Main, that confirms the issue is at the other server.

  • If it fails at Galaxy Main in the same way, a share link to that version of the workflow could be posted back, along with the shared history link, and we can review/help more that way.

Hope that gives some actionable choices to get this resolved!

Dear @jennaj,

Thank you very much for your help. I finally started again from scratch and it solves the problem.

Is it really impossible to provide the user with a running log like snakemake does?

Thanks again,


1 Like

The Galaxy history is the current record of workflow execution exposed to end users through the web interface. Admins of a server have access to logs/more details with some of that available to those using the API/custom scripts. Neither are currently GUI based.

Many tickets capture components of these changes (involves more than just new GUI views). If interested, please review here.

Can you indicate to me what are these files? Do you have a link to a documentation describing those?


Start here:

1 Like