Hi all, I am trying to customise modules resources on restart. In particular, if a module fails under a specific condition, I would like to relaunch that module under a different set of custom configs (currently in a different config file). We are trying to automatise the process and we might not know beforehand if that condition will be met or not. Is there a retry machinery in nf allowing me to do that?

It's a bit hard to understand what you want to do and an example would probably help. I think the answer is no or yes, depending on how you look at it - there's nothing specific for retries allowing you to change how things are called but you can use closures, allowing you to use free form groovy and can have things cooperating to achieve your goals.

Thanks for replying - I'll give a few more details to hopefully clarify We are working with a dada2 module that requires the following changes if, say, the input file is too big (the check might be different but for the sake of simplicity)

process {
    withLabel:dada2_resources {
        cpus = { 48 }
        memory = { 64.GB}
        time   = { 144.h }
        errorStrategy = 'finish'
        maxRetries = 0
    }
}

the standard config would be

cpus =   { 12   * task.attempt }
        memory = { 32.GB * task.attempt }
        time   = { 12.h   * task.attempt }
        maxRetries = 3

We first want to launch the standard config anyway. However, if it fails, two things should happen: • If it failed because the input file was too big, we'd considerably bump resources • If it failed for any other reason, we leave it to the classic restart machinery Maybe it helps, the check on the file could happen here (i.e. if

REMOVE_AMBIGUOUS_READS.out.noambig_out

is too big/complex) - we could add a value to

meta

to branch the channel out and launch DADA2 with either of the two configs

I'd probably recommend adding that meta and having the respective closures consider it if it's a retry. I should note that I think these are mostly things that should be up to the user to decide (resource usage, retry policy), but providing sensible/helpful defaults is fine - but nothing should be relying on having exactly that configuration (e.g. insist on some

containerOptions

or similar).

Thanks Pontus, I'll give all this a thought!