# Bug Report: Nextflow hangs indefinitely - without error - when invoking invalid operators on path objects

[mikesivley]

Update: I was incorrect in my understanding that invoking channel operators on path objects implicitly creates value channels. It does not. Explicitly creating a value channel containing the path object resolves this issue. Thus, the original issue is instead that invoking channel operators on path objects is invalid, but does not raise an error within nextflow. All other details described below remain relevant and the issue remains problematic.

Bug Report

Nextflow silently accepts operators like .splitCsv(), .map(), .filter(), etc. on value channels path objects, but these operations don't execute as expected, causing silent pipeline hangs with no error messages.

Current Behavior

When operators that expect queue channels are applied to value channels path objects, the pipeline exits clean (but incorrectly) or, in the case of channel joins, blocks indefinitely without raising an error:

Actual Result: Pipeline completes without error but outputs nothing; no error or warning. In complex pipelines, can cause the pipeline to hang indefinitely without clear cause.

Expected Result: Compile-time error or runtime warning indicating incompatible channel type for operator.

Why This is Problematic

1. Silent Failures: Pipelines don't crash - they just complete without error, or cause some operators (e.g. join) to hang indefinitely, making debugging extremely difficult
2. No Error Messages: Users have no indication of what went wrong
3. Difficult to Debug: Requires deep understanding of channel types and dataflow semantics
4. Time Wasted: Developers can spend hours debugging what should be a compile-time error

Minimal Reproducible Example

Correct usage:

workflow {
    def samplesheet = channel.fromPath("../test_sheet.tsv")  // Path object → loaded into a queue channel.
    samplesheet
        .splitCsv(header: true, sep: '\t')  // Operator doesn't trigger
        .collect()
        .view()
}

Run: nextflow run snippet.nf
Result: Prints the content of test_sheet.tsv

Incorrect usage:

workflow {
    def samplesheet = file("../test_sheet.tsv")  // Path object
    samplesheet
        .splitCsv(header: true, sep: '\t')  // Operator doesn't trigger
        .collect()
}

Run: nextflow run snippet.nf
Result: Prints nothing and exits clean (exit status 0).

Incorrect usage:

workflow {
    def samplesheet = file("../test_sheet.tsv")  // Path object
    samplesheet
        .splitCsv(header: true, sep: '\t')  // Operator doesn't trigger
        .collect()
        .view()
}

Run: nextflow run snippet.nf
Result: Prints Missing process or function view(), which is confusing given the existence of the view operator. The .nextflow.log file is slightly more detailed, but still unhelpful: Caused by: groovy.lang.MissingMethodException: No signature of method: java.util.ArrayList.view() is applicable for argument types: () values: [], because it doesn't explain why the channel is empty when the file clearly is not.

If the "channel" resulting from samplesheet.split.Csv is joined with another channel, it will cause the pipeline to hang indefinitely without warning or error.

Proposed Solutions

Add static analysis to detect when operators requiring queue channels are applied incorrectly to value channels path objects:

ERROR: Operator 'splitCsv' requires a channel but received a path
  at line 10: samplesheet.splitCsv(header: true)
  
  Hint: Use channel.fromPath() to convert path to a channel:
    def samplesheet = channel.fromPath(params.input)

Impact

This change would:

• ✅ Catch errors early (compile-time vs runtime)
• ✅ Provide clear, actionable error messages
• ✅ Reduce debugging time significantly
• ✅ Improve developer experience for newcomers
• ✅ Align with strict syntax goals in Nextflow 25.10+

Environment

• Nextflow version: 25.10.2.10555
• DSL version: DSL2

Additional Context

This issue was identified when I was attempting to parse and join the content of a samplesheet onto another channel. What I see as a user is that the pipeline runs up to a point and then hangs without submitting any additional work to the downstream processes. It does not fail and there are no process-level errors, so all I could see was that nextflow itself wasn't moving forward. Trying to understand why the channels weren't propagating data was very difficult to troubleshoot. It would have shortened my debugging considerably if the pipeline had failed with a type mismatch between, rather than masking the invalid use.

[bentsherman]

I'm confused, none of the examples you gave involve calling splitCsv on a value channel. fromPath() returns a queue channel and file() returns a Path value (not a value channel).

[mikesivley]

My understanding is that invoking splitCsv on a path value implicitly creates a value channel. However, my understanding or terminology may be incorrect. In either case, the silent error when invoking splitCsv on an invalid object remains problematic.

edit: I took your comment into my toy example and explicitly created a value channel for the path object (def samplesheet = channel.value(file("../test_sheet.tsv"))). This does indeed alter the behavior and the run does execute as it should, so the issue is the invocation on a path object, not a value channel. I will update my issue accordingly.

[mikesivley]

Of note, SeqeraAI provides incorrect information on this subject. That, or the information it provides is meant to be true, but there is a bug in the implicit creation of the channel. I don't know which behavior is intended by nextflow.

[bentsherman]

It is understandably confusing because splitCsv is defined both as an operator and a Path method. So when you call splitCsv() on a Path, it returns a list instead of a channel, and it no longer makes sense to call operators like collect or view.

This issue has been addressed by type checking, which is now available in the language server with Language Version set to 25.10 or later. It will show an error on this snippet for the call to collect and/or view. Eventually we will add it to nextflow lint and nextflow run but for now we're keeping it in the language server while it matures.

[mikesivley]

Understood. Thank you for the explanation. That also explains why nextflow lint wasn't catching it. I would still classify this as a bug until it is patched in nextflow itself, since the invocation of a channel operator on the list object returned from splitCsv does not raise an error and the invocation of join with an actual channel causes the pipeline to hang, rather than fail.