Skip to content

refactor: route precompute outputs on StoredOutputId, not a bare u64 - #787

Open
zzylol wants to merge 1 commit into
mainfrom
refactor/route-on-stored-output-id
Open

zzylol wants to merge 1 commit into
mainfrom
refactor/route-on-stored-output-id

Conversation

@zzylol

@zzylol zzylol commented Sep 29, 2026

Copy link
Copy Markdown
Contributor

Step 1 of #785.

The runtime's materialization index was keyed by a bare u64:

pub(crate) materializations_by_policy_fingerprint: HashMap<u64, PrecomputeMaterialization>,

The integer's meaning lived only in the field name, and that name points at PolicyFingerprint, which its own module doc calls a "Legacy routing wrapper" superseded by an explicit stored_output_id. Every caller had to know which of the two identities the integer was.

It is now keyed on StoredOutputId, whose doc says "Runtime routing uses this identity, never the semantic definition hash", and the field is materializations_by_output. runtime_materializations, the three accessors and the Index impl follow.

No serialized bytes change

Three things were verified rather than assumed:

  • InstalledPrecomputePlan is #[derive(Debug, Clone)] with no Serialize. Its doc calls it an internal execution index derived from a validated plan, and it is rebuilt by from_precompute_plan on decode.
  • PolicyFingerprint appears as a serde field on no struct. Both it and StoredOutputId are #[serde(transparent)] newtypes over the same u64, with conversions in both directions.
  • The one place the value reaches a published document is state_schema_id, which formats "{BACKEND_COMPAT}:summary-state:v1:{id}". Same number, identical string.

So no schema bump, which is a correction to what #785 originally claimed.

Fixtures

Tests keep holding raw ids. A #[cfg(test)] from_raw_ids says that once, at the boundary, instead of every fixture wrapping its literals, and From<u64> for StoredOutputId lets a value already established as an output id convert without ceremony. Production construction still goes through from_precompute_plan, which takes the ids from the plan.

What this does not do

It does not retire PolicyFingerprint. from_config still derives one from an explicit stored_output_id:

if let Some(output) = cfg.stored_output_id {
    return output.fingerprint();
}

So adoption changes how a fingerprint is computed, not whether one exists. Retirement needs stored_output_id to become required so that fallback has no callers; that is a separate change.

Validation

19 files, +156 / −111. cargo test -p data_plane --lib 946 passed, -p control_plane --lib 433 passed, cargo fmt --check and cargo clippy --all-targets with -D warnings clean.

Rebased onto main after #763 merged, so it targets InstalledPrecomputePlan rather than the StreamingConfig that #763 replaced.

🤖 Generated with Claude Code

The runtime's materialization index was keyed by a bare `u64` whose meaning
lived only in the field name, `materializations_by_policy_fingerprint`. That
name points at PolicyFingerprint, which its own module doc calls a "Legacy
routing wrapper", superseded by an explicit `stored_output_id`. Every caller
had to know which of the two identities that integer was.

Key the index on StoredOutputId, the type whose doc says "Runtime routing uses
this identity, never the semantic definition hash", and rename the field to
`materializations_by_output`. `runtime_materializations`, the three accessors
and the `Index` impl follow.

No serialized bytes change. InstalledPrecomputePlan is `#[derive(Debug, Clone)]`
with no Serialize at all, its own doc calling it an internal execution index
derived from a validated plan. StoredOutputId and PolicyFingerprint are the
same u64 behind two `#[serde(transparent)]` newtypes with conversions both
ways, so even `state_schema_id`, which does reach a published document, formats
the identical string.

Fixtures keep holding raw ids. `from_raw_ids` is the one place that says so,
rather than each test wrapping literals, and `From<u64> for StoredOutputId`
lets a value already established as an output id convert without ceremony.

This is step 1 of #785. It does not retire PolicyFingerprint: `from_config`
still derives one from an explicit `stored_output_id`, so adoption changes how
a fingerprint is computed rather than removing it. Retirement needs
`stored_output_id` to become required, which is a separate change.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant