✅ Deploy Preview for nextflow-docs-staging canceled.

One comment that come into my mind when reviewing the PR, but out of the scope of the PR. Can we have the same issue with input variables (val) in V1? Nothing in the documentation says that optional parameters are supported. I see a strange case, but not sure if it is done in nf-core modules or if optional parameters are just used for files?

Took a closer look — overall this is a clean, surgical change. The downstream wiring is correct: I traced both the [] (v1) and null (v2) returns through TaskProcessor.applyInputContextV2 (lines 1801–1884) and confirmed that null is skipped and re-validated against !param.optional with a clear error message. The Path? → isOptional()=true model is correctly leveraged.

One thing worth considering, plus a few nice-to-haves:

Important to consider

The original repro from #7161 (--intervals "") is not actually fixed — only omission is.

The new guard in ProcessEntryHandler.getValueForInputV1 only handles value == null. The reporter's command used --intervals "" (empty string), which means namedArgs.get('intervals') == "" (non-null) → falls through to parseFileInput("") → Nextflow.file("") → still errors.

Users naturally write --foo "" on the CLI to signal "no value", so this gap will likely come back as a follow-up bug report. One-liner fix:

if( value == null || (param instanceof FileInParam && value instanceof CharSequence && !value) ) {
    if( param instanceof FileInParam )
        return []
    throw new IllegalArgumentException("Missing required parameter: --${name}")
}

Or, document explicitly in the changelog / docs that the user must omit the flag rather than pass an empty string.

Nice to have

1. No log signal when v1 silently swallows a missing path input. A typo like --read vs --reads will now surface as a far-downstream task-execution failure with no hint that the root cause was a misspelled flag. Even a log.debug (or throttled log.warn1) noting "path input --${name} not provided, defaulting to empty list" would help post-mortem debugging.

2. No v1 negative test for non-FileInParam inputs. The new test covers the early-return for FileInParam, but there's no explicit assertion that e.g. ValueInParam still throws. The pre-existing should throw exception for missing required parameter test catches the regression by accident, but doesn't pin the contract of the instanceof FileInParam guard. Strengthening it to assert the exception message would make the contract explicit.

3. ProcessInput is mocked rather than constructed. It's a simple value object with a 3-arg constructor (name, type, optional) — using a real instance instead of Mock(ProcessInput) { ... } would make the v2 tests more refactor-resistant.

4. No changelog / docs update. This changes the failure semantics for nextflow module run with missing path inputs — worth a line in changelog.txt and a sentence in the nextflow module run docs.

Follow-up idea (not for this PR)

The PR notes that legacy processes have no way to declare optionality. The recently-merged meta.yml schema validation in #7094 makes ModuleSpec.ModuleParam a natural place to add an optional: true field — so getValueForInputV1 could honor that metadata via paramTypes (extended with an optional flag) and reject truly-required missing inputs while permitting truly-optional ones. Worth a follow-up issue.

Can we have the same issue with input variables (val) in V1? Nothing in the documentation says that optional parameters are supported. I see a strange case, but not sure if it is done in nf-core modules or if optional parameters are just used for files?

In theory yes, val inputs can also be optional. But in practice they tend to have a default value (0, false, '', etc) which is easy to supply on the command line.

This fix is needed for path inputs because of how the path string is being converted to a file path under the hood, so users need a way to circumvent that. Omitting the option is the simplest solution and also consistent with how optional file params work at the pipeline level