Workflow doesn't execute all steps after successfully being invoked.

jobs
workflow
dataset-collection
input
#1

Hi,
I’ve recently created a workflow for my ChIP-Seq analysis. I used the workflow to analyse new experiments and while there are 5 steps, only 3 steps are executed. I dont even see the other steps at all in the history.
Any suggestions on how to resolve this would be greatly appreciated.
Thanks,
Kris

#2

Could you share the workflow with us? At least a screenshot.

#3

Please see the workflow using the following link:
https://usegalaxy.org/u/gvk_96/w/chip-seq-analysis-for-heatmaps

My history shows steps till bamCompare are executed while Compute Matrix and HeatMaps are not.

#4

@jennaj could you please have a look, it seems valid to me at first glance

#5

The workflow looks connected correctly. I see one problem in the settings for BWA, that we have fixed but it is not yet published to usegalaxy.org yet (or anywhere else). However, that would result in a job failure at the BWA step (or possibly a warning). More is probably going on and we can help to find out what that is and get it fixed (server/tool side or the workflow itself).

@kriskris99 Would you please send in a link to a test history that contains all of the inputs and the results you get from executing the workflow. It would be best if this was isolated. So if you need to, copy the inputs into a new history, then execute the workflow, sending it back to the same history. Executing the workflow and sending it to a new history won’t include all of the inputs we’ll need to do troubleshooting tests.

Generate a history share link and put in a mail, along with the workflow share link again, and a link to this post (as reference) and send all to this mailing list: galaxy-bugs@lists.galaxyproject.org. This maintains your data privacy – only admins at usegalaxy.org will have access and only for troubleshooting purposes.

Note: Make sure all data is left undeleted. When you perform the share, click on the box to share “all objects” in the history before generating the link (unshare then re-share to double check this box is checked if you have already generated the link).

Errors with Varscan Somatic and GATK pipline
#6

I have been having the same issue for 2 months with a workflow successfully invoking but none of the steps ever show up in my history even after days.

Here’s the workflow: https://usegalaxy.org/u/lho-w/w/rnaseq-fastq-to-deseq
Here is the history containing the paired collection and GTF for the workflow : https://usegalaxy.org:/u/lho-w/h/293t

I have resorted to running the steps manually, and that seems to work.

Any advice is appreciated!

1 Like
#7

Hi Lena,

All workflows need to have “inputs” specified at the start. This wasn’t always true in the past, but is now for some technical reasons related to how data is consumed by tools.

Please see this prior Q&A for how to add an “input” representing a collection to your workflow:

#8

Thanks for your reply. “Input” was part of my original workflow. However, in workflow editor, the connector from “output” of “Input dataset” refuses to connect to the Trimmomatic Input when paired dataset (as collection) is selected. So I input the dataset straight into Trimmomatic when running the workflow. Any ideas why?

#9

Check the “collection input type” (shown in the lower right of the screenshot) versus the input type specified with Trimmomatic. If that is a match, try disconnecting the noodles going from Trimmomatic to downstream tools, save the workflow, connect the “input” to Trimmomatic, then reconnect downstream tools. This resets the data connection checks built into the workflow editor.

Let us know how that works – if it doesn’t, please share a copy of the workflow back that includes the collection input (disconnected) and we can review/offer help.

Thanks!

#10

I was able to do as you suggested (please check), but now the link to Hisat2 is not working due to the connection checks that you mentioned. It seems like I need to rebuild the paired-end collection before feeding back into Hisat2, but which operation should I use for this?

1 Like
#11

Ok, that’s not good. There was a problem around this before we thought was fixed. I’ll run a few more tests and report it to the developers.

To get around the problem for now, try removing all noodles and save. Then make a copy of the workflow. Open that copy in the editor, reconnect the noodles going from left > right within the editor, in the same path the data flows through the tools. Not ideal, but doing this has worked for me before.

#12

Update: We created a new ticket to address this usage problem. If interested, the ticket is here: https://github.com/galaxyproject/galaxy/issues/7431

In short, what you noticed and what I thought was going on turned out to still be an open issue. This manifests as incompatible connections when adding in a new or different “input type” if tools are already connected downstream based on a different (or absent) initial “input type”. We agree it would be much better if the “input type” was re-evaluated on the fly, during a workflow editing session (and that is what the ticket above is describing).

Removing all connections, then linking them back up (starting with the “input”) is how to get the “input type” to reset so that noodles will connect correctly between tools.

I am fairly certain that you can skip the “copy workflow” step I put in initially. Or instead, save a copy of your original workflow back first in case something else goes wrong and you need to start over but don’t want to completely start over!

Thanks again for reporting this :slight_smile:

Workflow is not operating on a collection
#13

I managed to get the workflow going following your instructions. However, I think think something is up with HISAT2. It is not executing and returns an empty list, so workflow stops. I also invoked HISAT2 separately as a standalone tool and it does not run with either collections or single fq.gz files.

1 Like
#14

Good that workflow connected, odd that HISAT2 is not running.

Could you clarify a bit more – When run by inself, is the job still gray (waiting to execute), or the result red (errored) or green with unexpected results? Or was there some problem submitting the job at all – does the tool form toss up a warning? That would indicate a problem with the inputs/settings, usually is highlighted.

We can troubleshoot from there, thanks!

#15

Before, the job turns green immediately after job submission and indicates “a list with 8 items” but it’s fact empty. Over the weekend, it seems that standalone Hisat2 jobs worked again but there is a long delay between submission (grey) and running (yellow).

In the workflow, that problem Is still happening,

ie HISAT2 becomes green when in fact the steps before it are still grey/yellow. The workflow then stops at Hisat2 and does not generate any further steps in the history downstream of Hisat2.

I know it’s a workflow (connector) bug because I can feed the same datasets manually through each step with the same settings as in the workflow.

1 Like
#16

Reviewing, feedback soon

#17

Hi - It looks like the workflow was still executing – your most current history looks Ok but I can’t tell what datasets were from a manual run or a workflow run.

It does take some time for all jobs to populate in the history. Even if the collection is “green” jobs might be executing inside of it. Downstream jobs dependent on that output will populate after complete in some cases.

Trying running the workflow without deleting any of the jobs until it fully completes (if that is not what your current results represent). If that fails for some reason or has incomplete results, please leave everything intact (do not delete), share the workflow, the source history (inputs), and the result history. It would be best to send the workflow results to a new history to keep it simple for review (avoid dataset/job confusion with any direct tool runs).

You can post those share links in the thread here or send me a direct message to keep it private.