process selector not working when full qualified name is used with negation

[anoronh4]

Bug report

Expected behavior and actual behavior

I would expect negation (!) would work to not match the rest of the pattern when the fully qualified name of the process is used. Instead, it seems like the negative is ignored, and it will do the opposite, i.e. match the pattern after the negation.

Steps to reproduce the problem

here's the script:

process A {
input:
val(x)
exec:
def args  = task.ext.args ?: "hi"
def args2 = task.ext.args2 ?: "hi2"
println args
println args2
}

workflow { A_workflow() }

workflow A_workflow { A(Channel.of(1)) }

here's the config:

process {
withName:'A_workflow:.*' {
    ext.args = "hola"
}

withName: "!A_workflow:A" {
    ext.args2 = "hola2"
}
}

i would expect the output would be hola hi2, instead if it's hola hola2

Program output

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

Launching `test.nf` [thirsty_davinci] DSL2 - revision: 44485f4459

executor >  local (1)
[d6/b37c56] process > A_workflow:A (1) [100%] 1 of 1 ✔
hola
hola2

there's some lines in the config file i wanted to show as well:

$ grep matches .nextflow.log
Oct-13 11:47:49.945 [main] DEBUG nextflow.script.ProcessConfig - Config settings `withName:!A_workflow:A` matches process A_workflow:A
Oct-13 11:47:49.948 [main] DEBUG nextflow.script.ProcessConfig - Config settings `withName:A_workflow:.*` matches process A_workflow:A

what the first line doesn't make sense. i also tried parentheses (withName: "!(A_workflow:A)") and single quotes, worked the same.

Environment

• Nextflow version: 25.09.1-edge
• Java version: 23
• Operating system: Linux
• Bash version: GNU bash, version 4.4.20(1)-release (x86_64-redhat-linux-gnu)

[bentsherman]

The negation for withName is implemented here:

nextflow/modules/nextflow/src/main/groovy/nextflow/script/dsl/ProcessConfigBuilder.groovy

Lines 172 to 177 in 253666d

	static boolean matchesSelector(String name, String pattern) {
	final isNegated = pattern.startsWith('!')
	if( isNegated )
	pattern = pattern.substring(1).trim()
	return Pattern.compile(pattern).matcher(name).matches() ^ isNegated
	}

This looks correct, but the issue might be with how the withName is applied:

nextflow/modules/nextflow/src/main/groovy/nextflow/script/dsl/ProcessConfigBuilder.groovy

Lines 52 to 61 in 253666d

	// -- apply settings defined in the config file using the process base name
	applyConfigSelectorWithName(configProcessScope, baseName)
	// -- apply settings defined in the config file using the process simple name
	if( simpleName && simpleName!=baseName )
	applyConfigSelectorWithName(configProcessScope, simpleName)
	// -- apply settings defined in the config file using the process fully qualified name (ie. with the execution scope)
	if( fullyQualifiedName && (fullyQualifiedName!=simpleName || fullyQualifiedName!=baseName) )
	applyConfigSelectorWithName(configProcessScope, fullyQualifiedName)

It tries to apply the withName three times:

1. first with the process base name
2. second with the process alias
3. third with the fully-qualified process name

It ends up making the following tests:

matchesSelector('A', '!A_workflow:A') // -> true
matchesSelector('A', '!A_workflow:A') // -> true
matchesSelector('A_workflow:A', '!A_workflow:A') // -> false

Because the tests with the unqualified names pass, the additional config is applied

I'll have to think about whether this logic can be re-arranged to be more "correct"

[bentsherman]

If I may ask, how are you using the negated withName in practice? I haven't used it much myself so I'm not familiar

I'm starting to think that having this negation operator isn't such a good idea. Maybe it was fine in DSL1, but now with include aliases and workflow prefixes, it kinda falls apart in the particular case that you found (negating a fully-qualified name)

I wonder if you can always achieve the same configuration without using the negation...