Parameter configuration resolution change when using strict syntax

[just-simon-5]

Bug report

When using strict syntax pipelines no longer resolves parameter configuration the same way. The first time the parameter is set, this is now the parameter value used by the workflow even if profiles/later configuration override this initial parameter value.

Expected behavior and actual behavior

Expected behaviour:
Parameters are overwritten when configuration redefines them.

Actual Behaviour:
Initial parameter value is used even when redefined later in the configuration.

Steps to reproduce the problem

I have attached a toy pipeline example you can use to recreate issue.

illustrate_configuration_resolution_issue_strict_syntax.tar.gz

Program output

export NXF_SYNTAX_PARSER=v2
nextflow run main.nf

N E X T F L O W ~ version 25.10.3

Launching main.nf [berserk_sinoussi] DSL2 - revision: 12815250a9

executor > local (1)
[09/a3e152] process > FOOBAR [100%] 1 of 1 ✔
foo

nextflow run main.nf -profile bar

N E X T F L O W ~ version 25.10.3

Launching main.nf [high_wilson] DSL2 - revision: 12815250a9

executor > local (1)
[e3/d564da] process > FOOBAR [100%] 1 of 1 ✔
foo

export NXF_SYNTAX_PARSER=v1
nextflow run main.nf

N E X T F L O W ~ version 25.10.3

Launching main.nf [drunk_noyce] DSL2 - revision: 12815250a9

executor > local (1)
[cd/968a7b] process > FOOBAR [100%] 1 of 1 ✔
foo

nextflow run main.nf -profile bar

N E X T F L O W ~ version 25.10.3

Launching main.nf [infallible_goodall] DSL2 - revision: 12815250a9

executor > local (1)
[66/a8c819] process > FOOBAR [100%] 1 of 1 ✔
bar

Environment

• Nextflow version: version 25.10.3 build 10983
• Java version: openjdk 21.0.2 2024-01-16 (build 21.0.2+13-58)
• Operating system: macOS
• Bash version: zsh 5.9 (arm64-apple-darwin25.0)

Additional context

(Add any other context about the problem here)

[bentsherman]

Duplicate of #6623

This will be fixed in the next edge release.

I wasn't sure whether to backport it to 25.10 as we are dealing with a lot of runtime bugs like this with the v2 parser.

One workaround that we found is to define the param default in the script instead of the config. This is best practice anyway, because params used by the script should be declared in the script.

[hanslovsky]

I have a similar issue going from v1 to v2, which is probably related (hence I will not open a new issue for now):

$ cat main.nf
workflow {
    println(params)
}

$ cat nextflow.config               
params {
    a.b.c = "def"
    d.e.f = params.a.b.c
}

v1 output:

$ NXF_SYNTAX_PARSER=v1 nextflow run . --a.b.c="123"

 N E X T F L O W   ~  version 25.10.4

Launching `./main.nf` [gloomy_sax] DSL2 - revision: d6543e5093

[a:[b:[c:123]], d:[e:[f:123]]]

v2 output, notably d.e.f remains unchanged at "def":

$ NXF_SYNTAX_PARSER=v2 nextflow run . --a.b.c="123"

 N E X T F L O W   ~  version 25.10.4

Launching `./main.nf` [wise_marconi] DSL2 - revision: d6543e5093

[a:[b:[c:123]], d:[e:[f:def]]]

If you don't think that this is related, I can also open another issue.

For reference, I also started a discussion on slack

[hanslovsky]

FWIW, my issue persists in 26.03.2-edge:

$ NXF_EDGE=1 nextflow self-update                  

      N E X T F L O W
      version 26.03.2-edge build 11799
      created 07-04-2026 21:29 UTC (17:29 EDT)
      cite doi:10.1038/nbt.3820
      http://nextflow.io


Nextflow installation completed. Please note:
- the executable file `nextflow` has been created in the folder: $HOME/.local/bin

$ NXF_SYNTAX_PARSER=v2 nextflow run . --a.b.c="123"

 N E X T F L O W   ~  version 26.03.2-edge

Launching `./main.nf` [irreverent_lamarck] revision: d6543e5093

[a:[b:[c:123]], d:[e:[f:def]]]

[hanslovsky]

The more I work on it / read up on nextflow documentation, I think that dynamic parameter overrides in nextflow.config is discouraged/not supported. Hence, am trying now to do all the parameter resolution for parameters that refer to other (dynamic) parameters inside my workflows.

Before I had everything defined in nextflow.config , e.g.

params.data.a
params.level.func.xyz = params.data.a

Now, I only define the this in nextflow.config

params.data.a

and all my workflows take an additional input data_params, so I can call my processes like this:

func(workflow_params.func ?: [:]) + [xyz: data_params.a])

Then I just need to pass data_params into each sub-workflow from the main workflow. I will report back if my test workflow runs successfully with this.

[bentsherman]

Closing since the issue was resolved

@hanslovsky your issue seems to be different. Feel free to open a separate issue if you want. At a quick glance, I think the issue is nested params -- they aren't supported as a "first-class" feature, although they may happen to work in some simple cases. I would try to use flat params, e.g. refactoring params.a.b.c as params.a_b_c