https://nf-co.re logo
Join Slack
Powered by
Hi everyone! I merged the release PR for genomeqc ...
# aws-megatests
f
Hi everyone! I merged the release PR for genomeqc 1.0.0. The AWS megatest was triggered, but it’s failing at the OrthoFinder step. It looks like the issue is with the 
mv
command in the orthofinder module. In the AWS megatest, 
mv
isn’t just renaming the output folder, instead it's doing a per-object copy-then-delete. The problem is that the output folder contains several subfolders and files, so it fails. Is there a way to bypass this? Or would the only option be to patch the module in the pipeline and remove the 
mv
line. I tried re-running the megatest and get the same error.
Here's the latest run: cloud.seqera.io/orgs/…/logs
r
I will try running it with scratch=true, but unfortunately this is how cloud storage behaves on 
mv
in general, so ideally it needs to be removed: https://cloud.seqera.io/orgs/nf-core/workspaces/AWSmegatests/watch/1viUssyTxXe4wB/logs
Adam did a bytesize about this a while back:

youtube.com/watch?v=…&pp=…▾

👍 1
f
Many thanks! I've talked to the othofinder module maintainer and he thinks the best option is to remove that 
mv
line from the official module. I guess what I'm wondering now is, how do I patch my pipeline? Given that it's already released on GitHub. Do I have to make a new release? Seems like overkill
Yeah, I'll have to remove that line, becauase it's still failing
Checking the AWSmegatests now orthofinder it's working. The process that uses Orthofinder's output is what's failing now. (cloud.seqera.io/orgs/…/logs). Not sure why that would happen, since the test_full works on my HPC. It says:
Copy code
Caused by:
  Can't stage file /nf-core-awsmegatests/work/genomeqc/work-e1aa8943b4752b9e540b2370aa2454ca9ba04742/e8/47053aa7611eb263f2923320e03288/orthofinder/Orthogroups/Orthogroups.tsv -- file does not exist
But that path does indeed exist.
p
I pointed Seqera AI at this run: cloud.seqera.io/orgs/…/logs It dug into the pipeline code for me, looks like you have a process that tries to directly access files in another processes' working directory
This is bad practice, precisely for this reason: it may work on a local / networked file system, but it won't work with cloud storage where different tasks might be running on totally different compute instances
seqera 🤖 💬
The pipeline fails because 
ORTHOSEQCOUNT
reaches into `ORTHOFINDER`'s task work directory to grab Orthogroups.tsv, using a path hand-derived from `ORTHOFINDER`'s directory output rather than receiving the file through a channel. Nextflow only guarantees the outputs a process explicitly declares, so on the AWS Batch S3 executor that nested file isn't reliably present at the derived key and staging fails, whereas on a shared local filesystem in CI the path happens to resolve, which is why the bug stayed hidden. The fix is to have the 
ORTHOFINDER
module declare `Orthogroups`/`Orthogroups.tsv` as a proper output so Nextflow resolves and publishes that specific file, then wire that output channel into 
ORTHOSEQCOUNT
and delete the file-into-directory workaround. The same treatment is needed for the v2 branch, and because orthofinder is a shared nf-core module the change should be applied via nf-core modules patch so it survives module updates.
f
Hi Phil, sorry I didn't see this. You are right, that's what it's doing. I'll have a look and see how easy would it be to change it. I might have to fix it in the local module. Once I fix it, should just I add this as a patch to the current version? Or should I patch it and make a new release?
p
ah, is it already released? Then a patch release please.
We try not to touch released pipelines unless it's there's a very good reason. Not sure that this qualifies.
Welcome to 
1.0.1
😅
You'll see on the nf-core newsletter list of released pipelines that there is often a fully of patch releases that follow a feature release. That's ok..
f
Will do! Thanks
👍🏻 1
5 Views
Open in Slack
PreviousNext
Powered by