Static typing disables named workflow outputs in Nextflow

Ask for help
1

According to Workflows (typed) | Seqera Docs, it should be possible to assign named outputs to subworkflows, using the syntax result: Value<Path> = val_bye. I then expected to be able to access the named outputs using dot-notation. However, the following example fails to execute:

nextflow.enable.types = true

workflow myWorkflowValue {
  main:

  val = channel.value(5)

  emit:
  my_data: Value<Integer> = val
}

workflow myWorkflowChannel {
  main:

  ch = channel.fromList([1,2])

  emit:
  my_data: Channel<Integer> = ch
}

workflow {
  main:

  result = myWorkflowValue()
  // result = myWorkflowChannel()
  s = result.my_data
}

producing the error

❯ nextflow run main.nf

 N E X T F L O W   ~  version 26.04.0

Launching `main.nf` [romantic_angela] revision: 329e302a9a

WARN: Static typing is a preview feature -- syntax and behavior may change in future releases
ERROR ~ No such variable: my_data

 -- Check script 'main.nf' at line: 26 or see '.nextflow.log' file for more details

The error occurs with both the channel version and the value version.

It seems that by enabling static typing, we also disable named outputs, but I cannot find any documentation about this.

Another example to illustrate this. Workflows | Seqera Docs (essentially) has the following example, which executes correctly

workflow my_workflow {
    main:
    ch_bye = channel.fromList([1,2])

    emit:
    my_data = ch_bye
}

workflow {
    result = my_workflow()
    result.my_data.view()
}

However, if I add nextflow.enable.types = true, then I once again get the same error:

❯ nextflow run main.nf

 N E X T F L O W   ~  version 26.04.0

Launching `main.nf` [maniac_noyce] revision: b6cc489e8a

WARN: Static typing is a preview feature -- syntax and behavior may change in future releases
ERROR ~ No such variable: my_data

 -- Check script 'main.nf' at line: 16 or see '.nextflow.log' file for more details
2

Actually, by following Migrating to static typing | Seqera Docs I was able to get it to work by simply using the subworkflow output directly, without using dot-notation:

nextflow.enable.types = true

workflow myWorkflowValue {
  main:

  val = channel.value(5)

  emit:
  my_data: Value<Integer> = val
}

workflow {
  main:

  output = myWorkflowValue()
  output.view()
}

However, this usage seems weird to me, since the my_data name is totally redundant.

More importantly, I also got it to work by just adding another output

nextflow.enable.types = true

workflow myWorkflowValue {
  main:

  val1 = channel.value(5)
  val2 = channel.value(6)

  emit:
  my_data1: Value<Integer> = val1
  my_data2: Value<Integer> = val2
}

workflow {
  main:

  output = myWorkflowValue()
  output.my_data1.view()
}

Commenting out the second output of myWorkflowValue breaks the entry workflow. I think this is a bug?

3

I think this behavior is a rough edge that results from allowing typed workflows to be used interchangeably with legacy workflows. To make a long story short, a single named output is a degenerate case since you don’t really need the name, so the simplest solution was to not support this case with static typing.

So the main two patterns are (1) a single output expression or (2) multiple named outputs. Which matches what you found. But I guess this rough edge should be documented somewhere