Hello! I have a question that is more theoretical than practical. My laboratory has to migrate to an S3 Object Storage system in the (near?) future, so I've been testing eager to work with files saved on an s3 bucket. Here are the version I've tested: • Eager v2 (revision 2.5.1) Nextflow v. 22.10.6 • Eager v3 (dev) Nextflow v. 26.04.7 The aws configuration parameters I used are the same for both tests. What I have noticed is that v2 had troubles with downloading the remote fastqs files: by looking solely at the size, they were 10 times bigger, and they were still compressed! Which created problems as soon as AdapterRemoval started. The error message was: "invalid FASTQ record; sequence/quality length does not match". The v3 (dev) version, instead, works smoothly and the fastq files are downloaded with no problem (yay!) My question is: is this issue related to the Nextflow version, rather than Eager? I've been digging through some old GitHub bug reports about Nextflow and AWS implementation, and it seemed that there were problems up to version 23.09.0 although the problems observed were not too similar to mine. In any case, it seems that our lab will have to migrate to v3 as soon as possible 😄

Hi Flavia! In short, yes. Nextflow deals with downloading remote files and staging them correctly internally. This is not something directly implemented within nf-core/eager code. It is possible that the way the files get staged within eager did not fully account for that (maybe using

file()

instead of

path()

etc might affect this?) Glad to hear that the dev version works well though! 💪

Thank you for the heads up! I definitely was very relieved when I saw that v3 works smoothly, so I will not dig into v2 further 🎉