Problem
Two public endpoints return the same config data in different forms:
// get_config_snapshot — Vec<SLAConfigEntry> in canonical order
let mut entries = Vec::new(&env);
for severity in Self::canonical_severities(&env) { entries.push_back(SLAConfigEntry { severity, config }); }
Ok(SLAConfigSnapshot { version: symbol_short!("v1"), entries })
// list_configs — the raw Map
pub fn list_configs(env: Env) -> Result<Map<Symbol, SLAConfig>, SLAError> {
env.storage().instance().get(&CONFIG_KEY).ok_or(SLAError::NotInitialized)
}list_configs returns the Map (map-internal ordering, raw SLAConfig values) while the snapshot guarantees canonical severity order with typed entries; both are in get_public_api.
Consequences:
- Consumers get different ordering guarantees for the same data: code reading
list_configs and iterating the map cannot rely on the canonical order the snapshot guarantees; a consumer that switched endpoints for efficiency would silently change its ordering semantics.
- Two shapes for one concept:
Map<Symbol, SLAConfig> vs. Vec<SLAConfigEntry> — serialization, iteration, and diffing logic must exist twice; offchain/readCostRegression.ts models config as a flat map (the list_configs shape) while the recommended bundle uses the snapshot shape, so even the repo's own tooling disagrees about the canonical shape.
- Neither endpoint is marked preferred: the docs describe both without saying which consumers should use, so new consumers pick arbitrarily and inherit whichever ordering contract.
Root cause
list_configs predates the snapshot; when the snapshot was introduced as the backend-friendly canonical order, list_configs was kept for compatibility without deprecation or cross-documentation.
Why this is architecturally hard
- The resolution options: deprecate
list_configs (an ABI-visible change; the descriptor and consumers must coordinate), re-document it as the raw/low-level view (leaving two shapes), or make it return the snapshot shape (a breaking change to its return type).
- The
Map return is also less stable across SDK versions (map ordering), so the "raw" framing is itself fragile — the issue should state which surface is canonical for new consumers.
- The descriptor-completeness companion issue's machinery should enforce that deprecated/alternative endpoints are marked, so consumers can tell.
Acceptance criteria
Out of scope
The snapshot version label (companion issue in batch 12) and the config-count semantics (companion issue in batch 06).
Getting started
Good first files to read: apexchainx_calculator/src/lib.rs (list_configs, get_config_snapshot), offchain/readCostRegression.ts.
Problem
Two public endpoints return the same config data in different forms:
list_configsreturns theMap(map-internal ordering, rawSLAConfigvalues) while the snapshot guarantees canonical severity order with typed entries; both are inget_public_api.Consequences:
list_configsand iterating the map cannot rely on the canonical order the snapshot guarantees; a consumer that switched endpoints for efficiency would silently change its ordering semantics.Map<Symbol, SLAConfig>vs.Vec<SLAConfigEntry>— serialization, iteration, and diffing logic must exist twice;offchain/readCostRegression.tsmodels config as a flat map (thelist_configsshape) while the recommended bundle uses the snapshot shape, so even the repo's own tooling disagrees about the canonical shape.Root cause
list_configspredates the snapshot; when the snapshot was introduced as the backend-friendly canonical order,list_configswas kept for compatibility without deprecation or cross-documentation.Why this is architecturally hard
list_configs(an ABI-visible change; the descriptor and consumers must coordinate), re-document it as the raw/low-level view (leaving two shapes), or make it return the snapshot shape (a breaking change to its return type).Mapreturn is also less stable across SDK versions (map ordering), so the "raw" framing is itself fragile — the issue should state which surface is canonical for new consumers.Acceptance criteria
list_configsis either deprecated, aligned to the snapshot shape, or explicitly documented as the raw variant with its ordering caveats.Out of scope
The snapshot version label (companion issue in batch 12) and the config-count semantics (companion issue in batch 06).
Getting started
just testGood first files to read:
apexchainx_calculator/src/lib.rs(list_configs,get_config_snapshot),offchain/readCostRegression.ts.