I’ve come across an odd issue I have not encountered before.
I have a collection of BAM alignments from STAR that I summarized with featureCounts.
I then used Tag elements (using tabular file) to tag the datasets in the featureCounts: Counts collection
I then tried to run DESeq2 using the tags to identify samples
The job began to run, but was then paused with the message "Input dataset ‘featureCounts on data 1 and data 33: Counts’ was deleted before the job started.’
I went to the tagged Collection, and each dataset had the correct tag. I clicked on the eyeball icon to view, and was first greeted with: “You are viewing a deleted dataset Undelete”
After 5-10 seconds, this then changes to display the dataset. I’ve tried clicking the undelete button, but as soon as I navigate away from the dataset and try to view it again I get the “You are viewing a deleted dataset Undelete” message. It’s almost as if internally Galaxy doesn’t realize the file exists at first. I suspect this is what is tripping up the run for DESeq2. Any ideas?
Would you please send in a bug report from the error job please? That will help me to find your account and review what is going on.
One thing to also try: copy those input datasets into a brand new history (first method here FAQ: Copy a dataset between histories). That can be the collection.
Sometimes that can reveal the true metadata state, and it also leaves your original history in a good state for review.
If the copy seems active/available, you can proceed from there. Copy over anything else you need (reference data, etc). Copies of data in your own account do not consume extra quota space, so a copy is “free” and seems worth a try.
The few times I’ve seen this it was due to some “extra” manipulations with Upload, but since that is not what you explain, I’d like to see what is going on exactly and come up with an explanation.
I’m not sure how the data got into this state, but it seems these were deleted by accident. I agree it should be easier to view the state and undelete when clicking into the collection, and since I can reproduce this it will be ticketed for a better UX experience. I’ll link that back tomorrow.
What to do:
Enter this text into the top search bar of the history panel: deleted:any visible:any. You can also click on the deleted then hidden tab to populate the search the same way.
Scroll down to the Featurecounts files: datasets 134-139 in your history
For each, click on the trash can with the arrow to undelete
That’s enough – so try rerunning the job once done. It worked for me in a copy of your history!
Let us know how this works for you, and thanks for the followup!
ps: Congrats on using tagged collections! This is a great feature so keep using it!
I’m not able to reproduce this. But as a guess, if you are doing this really fast, and the connection is not great (?) … try slowing down a bit to let the server catch up. Capture screenshots of the steps if you can, or even better, make a short video and send that into our mailing list (same place that bug reports go → galaxy-bugs@lists.galaxyproject.org).
What I did was: reveal all the datasets, undeleted those six files, then scrolled up and used the rerun button to launch the original job again. That caused the paused job to turn red, but the new job queued up and ran successfully. Could you try it that way first, too?
For this
It is because a deleted state is intermediate. Even some failed datasets will have the “eye” icon active and a file will display. Why? The file is still available (and counts toward quota) but it isn’t usable. Sort of like putting stuff in the garage before the trash, to make sure you really don’t need it! Then when running low on quota space, you can permanently delete (purge) anything you already marked as deleted in a batch.
Think of it as a sort of safety feature so you don’t accidentally purge something important. There are ways to purge directly, too, and that requires a double-click to confirm with a warning.
I was incorrect in stating that I got a message confirming that the undelete was successful. I tried to repeat it just now, and I don’t think the undelete link actually does anything. Rather, I had clicked on the undelete link and then the dataset was displayed (what you were describing below). I had interpreted that as the restore/undelete being successful. I guess my suggestion for a UX change would be to remove the undelete link if it doesn’t work in that instance - combined with displaying the dataset contents was what confused me.
Really appreciate the feedback, and while reproducing for a test case to report the display flip between the undelete link and file display, think I found a bug in the new release we have uploaded on the server. Good, we like to catch these early
