Skip to main content

resolve_stage_ref

Function resolve_stage_ref 

Source
pub fn resolve_stage_ref<'a, S>(
    id: &StageId,
    pinning: Pinning,
    store: &'a S,
) -> Option<&'a Stage>
where S: StageStore + ?Sized,
Expand description

Resolve a CompositionNode::Stage reference to a concrete stage in the store, respecting the node’s pinning.

  • Pinning::Signature: id is interpreted as a noether_core::stage::SignatureId; the resolver returns the store’s Active implementation for that signature.
    • If no Active match is found, the resolver falls back to store.get(id) and requires the looked-up stage to be Active. This fallback catches the case where a name- or prefix-resolver pass has already rewritten id into an implementation hash. It deliberately does NOT run Deprecated or Tombstone implementations — per STABILITY.md, deprecated stages should emit a warning when invoked, which a silent resolver cannot do. The right place for “run deprecated with a warning” is the CLI layer, not this helper.
  • Pinning::Both: id is an implementation-inclusive StageId; the resolver requires an exact store.get match. No fallback to signature-level resolution.

§Known gap (tracked as M2 follow-up)

In M2 only the type checker and runtime executor use this helper. The effect-inference walk, --allow-effects enforcement, Ed25519 verification pass, cost summary, planner parallel-grouping, budget collection, and grid-broker splitter all still call store.get(id) directly — which means a Pinning::Signature node can’t resolve through those paths yet. The follow-up “resolver normalisation pass” rewrites graph nodes to their resolved implementation IDs before anything else runs, so the rest of the engine keeps operating on concrete implementation hashes.