nextflow hangs with misnamed channel

[kpich]

Bug report

Nextflow seems to hang if you pass P.out.val from a process P that does not have an emit: val directive.

Expected behavior and actual behavior

I would expect an error. Instead (at least the local executor) seems to hang .

Steps to reproduce the problem

the following script

nextflow.enable.dsl=2

process PROCESS_A{
    output:
    path "f.txt"

    script:
    """
    touch f.txt
    """
}

process PROCESS_B {
    input:
    path inf

    script:
    """
    echo "in process b"
    """
}

workflow {
    PROCESS_A()
    PROCESS_B(PROCESS_A.out.val)
}

hangs indefinitely:

If you change the last line to have PROCESS_A.out.[any-other-string] it crashes as expected (and if you properly add emit: val to PROCESS_A it works).

(I discovered this in a process that generates a validation set - it's not an outlandish identifier, ha)

Program output

N E X T F L O W  ~  version 23.10.1
Launching `minimal.nf` [soggy_volhard] DSL2 - revision: f2380db67c
[-        ] process > PROCESS_A -

Environment

• Nextflow version: 23.10.1 build 5891
• Java version: openjdk version "21" 2023-09-19
• Operating system: macOS
• Bash version: zsh 5.9 (x86_64-apple-darwin23.0)

Additional context

[bentsherman]

It happens because the channel implementation (under the hood) has a val property which blocks until the channel value is available. But that won't happen until the script is executed, so it creates a deadlock. It probably only happens if the process has one output, with multiple outputs it might not be an issue.

We are working on some long-term language improvements that should address errors like this. For now it's just a pitfall you'll need to avoid