Static typing: false 'Argument … is not compatible' warning on process→process record wiring (cross-file check ordering)

[bentsherman]

Description

When a typed process's record(...) output is passed directly into another typed process whose input is the identical record type, the language server reports a spurious type-mismatch warning:

Argument with type Record is not compatible with process input of type Record {
    id: String
    data: Path
}

The producer's output type and the consumer's input type are structurally identical, and hover on the argument confirms it is fully structural (Channel<Record { id: String, data: Path }>). The warning appears to be a cross-file check-ordering issue: the consuming file is type-checked before the producer process's output type has been resolved, so the argument is momentarily seen as a bare Record.

Reproduction

Three files:

modules/producer.nf

nextflow.enable.types = true

process PRODUCER {
    input:
    record(id: String)

    output:
    record(id: id, data: file('data.txt'))

    script:
    """
    echo hello > data.txt
    """
}

modules/consumer.nf

nextflow.enable.types = true

process CONSUMER {
    input:
    record(id: String, data: Path)

    output:
    record(id: id)

    script:
    """
    cat ${data}
    """
}

main.nf

nextflow.enable.types = true

include { PRODUCER } from './modules/producer.nf'
include { CONSUMER } from './modules/consumer.nf'

workflow {
    ch_produced = PRODUCER(channel.of(record(id: 'sample1')))  // Channel<Record{id: String, data: Path}>
    CONSUMER(ch_produced)                                      // input: record(id: String, data: Path)
}

Type-checking the workspace reports, at the CONSUMER(ch_produced) call (main.nf:8):

warning: Argument with type Record is not compatible with process input of type Record { id: String  data: Path }

There are no real errors — PRODUCER's output Record{id: String, data: Path} satisfies CONSUMER's input record(id: String, data: Path).

Expected

No warning.

Observations that point to a resolution race / staleness

• Deterministic in a cold/headless full-workspace scan — driving the server over stdio and collecting published diagnostics reproduces it every run (3/3).
• In VS Code / a long-lived server the warning clears as soon as the consuming file is re-checked after the modules have resolved — e.g. adding/removing a blank line in main.nf makes it disappear.
• Editing a module does not re-check its consumers, so a stale false warning lingers in the editor until the consuming file is touched.
• Feeding a same-shaped record from a named record type channel (Channel<MyRecord>) or from .map { record(...) } does not trigger it — only a value taken directly from an upstream process's output does. This is consistent with the producer's output type not being resolved at the moment the consumer call is checked.

Versions

• language-server v26.04.1 and v26.04.2 (both reproduce)
• Nextflow 26.04.4