Hi all, We're running an internal minimal demultiplexing workflow based on the nf-core

BCLConvert

module (same module code as

nf-core/demultiplex

) on Seqera Platform + AWS Batch. We're processing a large Illumina run (~870 GB). Interestingly, the same dataset completes successfully with the official

nf-core/demultiplex

pipeline, but fails in our simplified workflow. When

scratch

and

stageInMode

are disabled, BCLConvert eventually hangs and is reset by the DRAGEN watchdog:

Hang detected - there has been no system activity for 600 seconds

No I/O activity detected for 600 seconds

The DRAGEN WatchDog service is resetting DRAGEN

When

scratch=true

and staging is enabled, the job instead fails due to local disk exhaustion:

zerolog: could not write event: write /tmp/fusion.log...: no space left on device

Fusion metrics show: download: ~869 GB available_disk: start: 1.8 TB end: 20 kB We've tested: • 500 GB and 1000 GB local disk • scratch enabled/disabled • same BCLConvert version (

4.4.6

) Since the official

nf-core/demultiplex

pipeline succeeds on the same input, I'm wondering if there are any workflow-level staging/localization steps that we're missing by using the module directly. Has anyone seen: 1. BCLConvert hanging when reading through Fusion/S3-backed storage? 2. BCLConvert requiring full localization of large run folders? 3. Differences in how

nf-core/demultiplex

handles large BCL inputs vs invoking the module directly? Any pointers would be much appreciated. Thanks!

I had an issue with fusion where it was iterating through all s3 files with the prefix, not just the folder that matched exactly. So I had a NovaSeq X run that demultiplexed fine when it was s3://bucket.name/foo, but after another run had been added with s3://bucket.name/foo_again, it was trying to stage both of them at the same time and ran into a s3 limit.