Disable resource prediction for processes referencing task.memory

[pditommaso]

Summary

Detect at compile time which task directives a process depends on, so that an executor which
adjusts the compute resources after the script has been rendered can react.

The motivating case is the Seqera scheduler resource prediction model: it may allocate less memory
than the task requested, but the script is rendered before the task is scheduled, so a script
referencing task.memory carries the value that was requested:

process FOO {
    memory 8.GB
    script:
    """
    java -Xmx${task.memory.toGiga()}g -jar app.jar
    """
}

-Xmx8g is baked into the command even when less is allocated, and the task fails with an
out-of-memory error.

How

DirectiveRefCollector walks the AST and the collected names are carried to run time, so nothing
has to be evaluated:

• Process definition — the script, the stub and the process directives are traversed when the
  process is transformed to Groovy; the names travel on the new BodyDef.directiveRefs.
• Config file — a dynamic directive value is necessarily a closure (task is not defined in the
  config scope, so the interpolated form is rejected at parse time), and closures retain no source
  at run time. The names are therefore attached to the value itself via DirectiveRefsClosure.
• shell blocks and template files — rendered by the template engine, so they are reported
  through the existing TaskRun.templateVars.

TaskRun.isDirectiveReferenced(name) returns the union. nf-seqera uses it to submit the affected
tasks with prediction model none and warn once per process; an explicit seqera/predictionModel
hint still takes precedence.

Covered

Where task.memory is referenced
script: / exec: block	✅
shell: block	✅
template file	✅
stub: block	✅
Process directives (ext, beforeScript, containerOptions, …)	✅
Config process.ext.args = { … }, incl. withName: / withLabel: selectors	✅
Config directives nested in list/map literals	✅

Names are matched against the DirectiveDsl declarations, so the task properties that are not
directives (task.attempt, task.name, task.exitStatus, …) are correctly ignored.

directiveRefs deliberately does not contribute to the task hash, unlike valRefs, so resume
caches are unaffected.

Remaining gap

NXF_SYNTAX_PARSER=v1 — the legacy parsers do not go through ProcessToGroovyVisitor* /
ConfigToGroovyVisitor, so the set stays empty and the check never fires. It degrades silently to
the current behaviour rather than failing.

Test plan

3759 tests across :nextflow, :nf-lang and :plugins:nf-seqera, 0 failures.

New: ProcessDirectiveRefsTest, ConfigDirectiveRefsTest, and the prediction cases in
SeqeraTaskHandlerTest.

Two defects found in review are fixed in c02168b and pinned by tests — neither was caught by the
first (fully green) CI run:

• withName: / withLabel: blocks are copied verbatim into every process config by
  ProcessConfigBuilder#applyConfigDefaults, so a single selector using a dynamic directive made
  every process report the reference.
• ClosureToStringVisitor runs after ConfigToGroovyVisitor and only knew about a plain closure
  expression, so wrapped values broke nextflow config and the config generated by kuberun.

[netlify]

✅ Deploy Preview for nextflow-docs canceled.

Name	Link
🔨 Latest commit	02f906c
🔍 Latest deploy log	https://app.netlify.com/projects/nextflow-docs/deploys/6a802fa43188880008124542

[bentsherman]

My initial reading -- this PR seems like overkill, and a mixture of concerns that I'd prefer to avoid right now (we are trying to stabilize the strict parser with all the new language features)

I would just document it as a pitfall for now -- resource prediction doesn't mix well with task scripts that encode specific memory requests -- and see what solutions emerge before adding more compiler magic. It may be possible to write the process script in a better way (e.g. use memory % instead of memory GB) or disable optimization manually for specific processes

[pditommaso]

Fair concerns, thanks for the read. A few thoughts:

I did first try to solve it entirely inside nf-seqera, but every version of that ended up hacky and still missed cases (shell, templates, beforeScript, config closures). That's what pushed me here: rather than a local hack, it seemed better to have a consistent way to track directive usage — this follows the same model we already use for task variables, so it's not really new machinery so much as an extension of an existing one.

You're right that it's broader than the immediate problem. That's somewhat deliberate, but I take the point about timing given the parser work. Also worth noting most of the diff is config introspection, which we can simplify once task.ext is deprecated/removed.

On documenting it as a pitfall: I'd rather not, at least not as the only answer. For Intelligent Compute the bar is that users get a good result without having to know about extra settings or rewrite their scripts — that part isn't negotiable for me. Happy to discuss scoping this down or staging it, though, if that helps land it more safely.

[bentsherman]

I have created an alternative PR: #7505

It keeps the nf-seqera consumer logic and tests, but implements the directive-ref collection in a much simpler way. It just reuses the existing valRefs to capture all task property refs instead of only task.ext. This actually matches what the v1 parser was doing.

We can make this simplification because we don't need to cover directive-refs in process directives or config. I have not seen examples of task.memory being used in this way

Since this is a stop-gap fix anyway and the ultimate goal is to find a way to re-enable the optimization, I opted for a targeted fix

[pditommaso]

Closing in favour of #7506