Cross-edge type checking silently skipped for edges sourced from single-operator (`operator:`) nodes

[phil-opp]

Note: This issue was created by an automated, scheduled Claude code-review check. Please verify before acting on it.

Summary

check_type_annotations_full (the dora build / dora graph --validate type-annotation checker) never performs cross-edge type-mismatch detection or type inference for any edge whose source is a single-operator node (a node declared with the operator: block). Multi-operator (operators:) source nodes work correctly. The result is that a real type mismatch on such an edge produces no warning, and in --strict mode it produces a misleading warning instead.

Root cause: a key-shape mismatch caused by running the check pre-resolution

In libraries/core/src/descriptor/validate.rs, operator outputs are registered into output_type_map with an operator-id-prefixed key:

// single-operator node (line ~890)
let op_id = op.id.as_ref().map(|id| id.to_string())
    .unwrap_or_else(|| super::SINGLE_OPERATOR_DEFAULT_ID.to_string()); // "op"
...
output_type_map.insert((nid.clone(), format!("{op_id}/{output_id}")), urn.clone());

The consumer-side lookup uses the mapping exactly as written in the descriptor (line ~1108):

let key = (mapping.source.to_string(), mapping.output.to_string());
let upstream_urn = output_type_map.get(&key);

check_type_annotations_full runs on the unresolved descriptor — both callers (binaries/cli/src/command/validate.rs:153 and binaries/cli/src/command/build/mod.rs:376) invoke it before resolve_aliases_and_set_defaults(). In the unresolved descriptor, a consumer of a single-operator node writes the bare output name (source: A, output: out). The op-id prefix (A/op/out) is only added later, during resolution:

// libraries/core/src/descriptor/mod.rs:105-107
if let Some(op_name) = single_operator_nodes.get(&mapping.source).copied() {
    mapping.output = DataId::from(format!("{op_name}/{}", mapping.output));
}

So at check time the producer key is (A, "op/out") but the consumer lookup key is (A, "out") — they never match, and upstream_urn is always None. This drops the edge into the "no upstream type" branches:

• non-strict: (None, Some(in_urn)) → _ => {} — the mismatch check and the (Some, None) inference branch are both skipped.
• strict: (None, Some(in_urn)) → emits "upstream A/out has no type annotation" even when the operator does declare output_types for that port — a false/misleading warning.

The multi-operator (operators:) form is unaffected because there the consumer writes the operator id verbatim (A/opid/out), so the lookup key already matches the registered key. I confirmed the default op id used on both sides is the same constant (SINGLE_OPERATOR_DEFAULT_ID = "op"), so the divergence is purely bare-vs-prefixed, i.e. an ordering bug — not intentional.

Reproduction (conceptual)

A single-operator node A declaring output_types: { out: std/core/v1/Float32 }, feeding a consumer with input_types: { x: std/media/v1/Image } and inputs: { x: A/out }, produces no type-mismatch warning from dora build / dora graph --validate. The equivalent dataflow written with the operators: (multi-operator) form does warn.

Impact

Advisory subsystem only — it does not accept an invalid dataflow or reject a valid one; the dataflow still runs. But the type-annotation feature (mismatch warnings + inference) silently covers only part of the graph, and --strict emits an incorrect "no type annotation" message for these edges.

Suggested fix

Either run the annotation check after resolve_aliases_and_set_defaults() (so consumer outputs are already op-prefixed), or normalize the single-operator consumer key at lookup time in check_edge_mismatches_with_compat — apply the same {op_id}/{output} prefixing the resolver uses when mapping.source is a single-operator node before probing output_type_map. A regression test covering an operator:-sourced edge (both mismatch and inference cases) would lock this in; the existing tests appear to exercise only the operators: form.

[phil-opp]

This appears to be already fixed on current main — no code change is needed.

check_type_annotations_full now registers a single-operator: node's output under both the op-id-prefixed key and the bare output_id, which is exactly the "normalize the key at registration/lookup" fix suggested here (libraries/core/src/descriptor/validate.rs):

output_type_map.insert((nid.clone(), format!("{op_id}/{output_id}")), urn.clone());
output_type_map.insert((nid.clone(), output_id.to_string()), urn.clone());

Since the pre-resolution consumer lookup uses the bare output name for an operator:-sourced edge, the bare key now matches and the upstream type is visible — so mismatch detection and inference both fire for these edges. Regression tests covering the operator: form were added: infers_type_across_single_operator_edge and detects_mismatch_across_single_operator_edge.

I verified this against the tip of main (de7f6ca). Flagging for a maintainer to confirm and close as resolved.

---

Generated by Claude Code

[phil-opp]

Triage: this appears to be already fixed on current main.

In libraries/core/src/descriptor/validate.rs, single-operator (operator:) node outputs are now registered under both the op-id-prefixed key and the bare output_id, so short-form consumer edges resolve against the pre-resolution descriptor:

output_type_map.insert((nid.clone(), format!("{op_id}/{output_id}")), urn.clone());
output_type_map.insert((nid.clone(), output_id.to_string()), urn.clone());

Three regression tests cover the fix: infers_type_across_single_operator_edge, detects_mismatch_across_single_operator_edge, and strict_mode_no_false_positive_across_single_operator_edge. This can likely be closed.

---

Generated by Claude Code

[phil-opp]

This looks already resolved on main (commit 0532878, merged 2026-07-24 — after this issue was filed).

check_type_annotations_full now registers a single-operator: node's outputs under both the prefixed and the bare key, so the consumer's short-form lookup key (A, "out") matches — libraries/core/src/descriptor/validate.rs:969-983:

for (output_id, urn) in &op.config.output_types {
    if registry.resolve(urn).is_some() {
        // A consumer of a single-`operator:` node references its
        // output in short form (`node/output`) in the source YAML;
        // the `op/` prefix is only injected later by
        // `resolve_aliases_and_set_defaults`, which this pre-build
        // check never runs. Register both the prefixed key and the
        // bare `output_id` so short-form edges resolve here too ...
        output_type_map.insert((nid.clone(), format!("{op_id}/{output_id}")), urn.clone());
        output_type_map.insert((nid.clone(), output_id.to_string()), urn.clone());
    }
}

Two regression tests cover this exact edge: infers_type_across_single_operator_edge and detects_mismatch_across_single_operator_edge (validate.rs:2567, :2600). The dropped-mismatch and misleading-strict-warning behavior described here no longer reproduces, so no further change is needed. Suggest closing.

---

Generated by Claude Code