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

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.

Start with the DSL2 reproductions in snippet.nf and run them with nextflow run snippet.nf, comparing channel.fromPath with a direct file path. Trace the resulting operator behavior and .nextflow.log; done means invalid operators on path objects produce a clear type error or warning instead of silently completing or hanging.