I've run into a curious issue trying to use the

RMARKDOWNNOTEBOOK

module and I wonder if anyone has any insight. There seem to be some operations that cause pandoc to run out of memory during its rendering phase, so it fails with an error 137. However, that error code isn't propagated back up to nextflow, (since pandoc was launched internally by R, I think), so the process just fails outright rather than retrying with more memory. Is this (or something similar) something anyone else has seen? (Why pandoc is dying is a whole separate issue. I haven't been able to make a small reproducible example, but in my specific case, commenting out the display of a small

plotly

figure makes it work fine. The other thing I've found that helps is setting

self_contained: false

in the YAML header.)

How much memory are you giving to this process?

Respectfully, that's somewhat beside the point. I can increase the amount of memory available to the process and it will run fine (in most cases), but that's not my question. Processes are set to retry a failed run with more memory, but it seems like that only happens for a specific subset of error codes. Here's the relevant line in

base.config

(which seems to be default to nf-core pipelines):

errorStrategy = { task.exitStatus in ((130..145) + 104 + 175) ? 'retry' : 'finish' }

But as I said, pandoc is launched by R, so when pandoc fails with error 137, R detects that it's failed, but doesn't propagate that error, so the process itself fails with a more generic error code, and nextflow doesn't initiate the re-try.

okay, well, if you do not want to give the process appropriate memory to begin with, you could adjust this for that process with:

process {
    withName RMARKDOWNNOTEBOOK {
        errorStrategy = 'retry'
    }
}

in some config