[vjaganat90]

What

• The Nextflow target reads sophios.ir.resolved, a read-only view of the compiled graph, instead of a copy of the CWL Sophios emitted. The view resolves what the graph already says (each step input's sources and the type it delivers, the parsed when and scatter, workflow inputs and outputs, the run policy) and gives none of it a meaning of its own. The CWL target does not use it and is unchanged.
• A refusal names the line its author wrote, the step and the construct. For docs/cookbook/when.wic with --target nextflow:
  • before:

    - steps[0].in.enabled: the step's when reads an input its tool does not declare, which is not supported
    - workflow.inputs.loud: required workflow input value is missing
    

  • after:

    - when.wic:9:16: step 'echo': input 'enabled': the step's when reads an input its tool does not declare, which is not supported
    - when.wic:2:3: workflow 'when': workflow input 'loud': required workflow input value is missing
    

  From Python the line is in the script. An input Sophios made for a step is refused at the line that gave it its value, as scatter_pyapi.py:13:1: step 'array_indices': ….
• The expression subset (parse, type check, canonical form) moves from nf_expr to lang.subset, since the view types a when with it. nf_expr keeps the Groovy rendering and reading.
• The Nextflow test cases compile through compile_source against their own tools, so each case is a workflow someone could write.
• An array-typed text capture (type: string[] with outputEval: $(self[0].contents)) crashed with TypeError. It is refused at its line now: one string cannot fill a string[].

Deleted

• The CWL projection, CompiledNextflowSource and compilation_result_source, with the analyses that read CWL fields back out of it. They rebuilt the workflow from a deep copy of the emitted CWL, which is why refusals named CWL paths. The agreement test that held the view to the projection goes with it; two import-linter contracts keep the target off emitted CWL and the view on the graph.
• 21 Nextflow test cases no compiled workflow reaches: they built CWL by hand that the compiler refuses before the target sees it.
• Two refusals the compiler always makes first, "has no source; wire it" and "carries … elements but the port takes" (wic032, wic023 or api003), with the helpers that only fed them, and a second copy of the undeclared-input refusal.

CI

• test_build_wheel's package job runs only what no other pull-request lane runs: the tests marked package and the Nextflow tests that do not run Nextflow. Tests that only weekly lanes run no longer gate a pull request.
• A cwl_corpus marker names the tests that run or read the CWL corpus (mm-workflows and image-workflows). Python Matrix Weekly runs the rest of the suite on 3.11-3.14, leaving out cwl_corpus, nextflow_corpus and skip_pypi_ci.
• test_ci_coverage.py counts pull-request and weekly lanes, not the release lane, so a test no such lane runs fails it.

What changes for users
Only refusal text. Every generated Nextflow file and all emitted CWL are byte-identical over the docs examples, the test cases and both corpora; CI does not check that, so I did. The Python API, the command line and .wic are unchanged.

Why
The Nextflow target worked backwards from the CWL Sophios wrote, so its refusals pointed at CWL nobody wrote, and every new target would have had to do the same. The view is the one place where a compiled workflow is read, for every target but CWL.

[darkclad]

I checked the byte-identity claim by compiling all 36 .wic files under docs/tutorials and docs/cookbook with --target nextflow on the merge base and on this head. All 136 generated files are identical, the exit codes match, and every refusal from base is still there, now with a line and step. The lang.subset move is a faithful move, and the import-linter contracts pass. The one red CI job, Run Workflows, failed on quay.io timeouts during cwl-docker-extract, which has nothing to do with this change.

I left three comments inline. The first is a behavior change rather than a text change: an output the lowering used to refuse is now dropped without a refusal.

[darkclad]

When a call leaves a nested input unbound and the input has no default, the input gets no entry in child_env. through() then resolves it to () (line 481). In _workflow_output_connections, a root output whose outputSource relays that input gets no connection and no refusal, so it is dropped from the Nextflow workflow without a word.

Repro: a nested child.wic declares extra: 'File?' and passed: {type: 'File?', outputSource: extra}, and the call binds only message. The CWL target emits the root output child~passed. output_sources(view) gives () for it, and NEXTFLOW.lower succeeds with only child_out and child_say_out. nextflow_names(view) still lists child~passed. Base refused the same workflow (resolved edge names non-executable source step ... 'child.wic'). That message was poor, but it was a refusal.

Two possible fixes: give an unbound, no-default input a Crossing, or refuse a kept output whose resolved sources are empty. Either restores the refusal, now at the output's line.

[vjaganat90]

Fixed in cadb0cd and 852cfc2, and it is now a refusal again, at the line that causes it.

The resolver records each miss where it happens: an input that a call leaves unbound and that has no default. output_unbound, beside output_sources, gives the misses each root output's resolution reached. The lowering refuses every kept output that resolves to nothing, once per unbound input, at the call that leaves it unbound:

step 'child': input 'extra': a workflow output relays it, but nothing binds it and it has no default

rejected/calls.yaml covers your repro, the same relay one call deeper, and a chain that reaches the output through another call's output. Tool-step inputs still resolve as before, and the 36 docs .wic files compile identically to master.

[darkclad]

Before this change, this job ran -m "not skip_pypi_ci and not nextflow", nearly the whole suite. It was the only PR lane for about 94 test functions, which now run only in the weekly lanes. Most of them are fast core tests: test_lang_parser.py (32), test_lang_schema.py (11), test_names_emitted.py (10), test_lang_render.py (9), test_canonical_path.py and test_reference_compatibility.py (6 each), and test_leak_boundary.py (5). The corpus parse and round-trip checks over the in-repo tutorials (test_corpus_files_parse, test_corpus_round_trips, test_accepts_the_whole_corpus) are now marked cwl_corpus, but neither Run Workflows nor Lint And Test collects them. Only Property Weekly runs them. So the new cwl_corpus marker text in pyproject.toml and the header of python_matrix_weekly.yml overstate where they run.

After this change, a parser, schema or emitted-name regression passes PR CI and shows up only in the weekly run. Could these fast files keep a PR lane, either by marking them package or by giving them a Lint And Test step?

[vjaganat90]

You're right that these no longer gate PRs. Putting all 94 back as they are isn't the fix, though. About 35 of them are already properties, and most of the rest are examples written before the property in the same file covered them, or checks on how a module is built rather than what it does. test_parse_case alone runs 137 inline snippets. A follow-up on top of this stack folds them into about 25 tests, one property per rule plus a few readable .wic examples in files for the diagnostics and the emitted names, and those gate PRs again. Until it lands they run in the weekly lanes.

On cwl_corpus: CORPUS (tests/core/wic_corpus.py) is whatever search_paths_wic reaches. That is the same discovery test_run_workflows_on_push runs, and in CI it covers mm-workflows, image-workflows and docs/tutorials. The in-repo fallback is only what Property Weekly sees, because it has no config. So the marker is right. You're also right that no PR lane collects these three: Run Workflows picks its tests by name. The follow-up makes them one corpus test.

[darkclad]

This assertion is looser than the one it replaces. Base matched the exact path plus the note (- steps[0].run.inputs.x.secondaryFiles: <note>). Here, _refused already keeps only the refusals whose reason ends with the note, and the notes contain the field name, so name in f"{subject} {reason}" is true for almost every row. That leaves only the construct check, and tool covers both input and output secondaryFiles. A refusal on the wrong port or class would still pass. Could this pin refusal.subject the way the NetworkAccess and requirement-class tests below do, for example T.cwl: inputs.x.secondaryFiles?

[vjaganat90]

Fixed in 0b58b86. The test now asserts refusal.subject exactly, the way the NetworkAccess and requirement-class tests do: the port for a workflow-side class, and the path in the tool otherwise, e.g. T.cwl: inputs.x.secondaryFiles. A refusal moved to outputs.o now fails three rows that the old assertion passed.

[vjaganat90]

Thanks for checking. The inline points are answered in their threads: the dropped output is a refusal again, at the call that leaves the input unbound; the support-table rows assert the exact subject; and the fast core tests will gate PRs again through a follow-up that shrinks them first. Run Workflows on the new head is the run to read.

[darkclad]

LGTM. My repro of the dropped output is now refused at the call, at wf.wic:4:3: step 'child': input 'extra': …, and the support-table rows pin the exact subject. On 6bce14c the 36 docs .wic files still give Nextflow output byte-identical to master. The Nextflow tests that don't run Nextflow pass locally (1283), and CI is green. I'll look for the follow-up that puts the fast core tests back on a PR lane.