Problem
Both snapshot endpoints return a version label that never changes:
// get_config_snapshot and get_custom_config_snapshot (src/lib.rs, src/config.rs)
Ok(SLAConfigSnapshot { version: symbol_short!("v1"), entries })The struct doc says version is a "Schema version label (e.g., "v1")" — a version that is supposed to change when the snapshot's structure changes. It is a literal in every call site.
Consequences:
- Structural additions ship with no signal: if
SLAConfigSnapshot gains a field (e.g. custom entries folded in, per the companion issue), the version label still reads "v1", so consumers that version-check snapshots before decoding cannot detect the change — the label's entire purpose is defeated.
- The label and the actual schema already disagree in meaning: "v1" now means "canonical-only snapshot"; a future "v2" would be ambiguous (structure change vs. content change), because the label is defined by neither the struct layout nor the content class.
- There is no test tying the label to anything: no test asserts "version bumps when entries shape changes" (impossible to write meaningfully today since the label is a constant).
Root cause
The version field was added as a placeholder label and never wired to a versioning mechanism (unlike RESULT_SCHEMA_VERSION, which has a constant and sentinel tests).
Why this is architecturally hard
- Making the label meaningful requires a schema-version constant (like
RESULT_SCHEMA_VERSION) bumped deliberately when the snapshot shape changes, plus a sentinel test — the SLAResult pattern the repo already uses.
- Alternatively the field can be removed from
SLAConfigSnapshot (an ABI change — the struct is #[contracttype] and stability-guarded) if consumers never use it.
- The custom-snapshot companion issue (adding custom entries to snapshots) is exactly the structural change that would exercise the versioning; the two should be planned together so the bump has a real trigger.
Acceptance criteria
Out of scope
Folding custom entries into the snapshot (companion issue) and the get_result_schema versioning (which already has schema_version).
Getting started
Good first files to read: apexchainx_calculator/src/lib.rs (get_config_snapshot, get_custom_config_snapshot), apexchainx_calculator/src/lib.rs (RESULT_SCHEMA_VERSION).
Problem
Both snapshot endpoints return a version label that never changes:
The struct doc says
versionis a "Schema version label (e.g., "v1")" — a version that is supposed to change when the snapshot's structure changes. It is a literal in every call site.Consequences:
SLAConfigSnapshotgains a field (e.g. custom entries folded in, per the companion issue), theversionlabel still reads "v1", so consumers that version-check snapshots before decoding cannot detect the change — the label's entire purpose is defeated.Root cause
The
versionfield was added as a placeholder label and never wired to a versioning mechanism (unlikeRESULT_SCHEMA_VERSION, which has a constant and sentinel tests).Why this is architecturally hard
RESULT_SCHEMA_VERSION) bumped deliberately when the snapshot shape changes, plus a sentinel test — theSLAResultpattern the repo already uses.SLAConfigSnapshot(an ABI change — the struct is#[contracttype]and stability-guarded) if consumers never use it.Acceptance criteria
RESULT_SCHEMA_VERSION.Out of scope
Folding custom entries into the snapshot (companion issue) and the
get_result_schemaversioning (which already hasschema_version).Getting started
just testGood first files to read:
apexchainx_calculator/src/lib.rs(get_config_snapshot,get_custom_config_snapshot),apexchainx_calculator/src/lib.rs(RESULT_SCHEMA_VERSION).