Skip to content

sla_calc omits config_version_hash while set_int and dup_input carry it: the primary decision event cannot be attributed to a config generation #518

Description

@usmanimamu17-create

Problem

The three decision-carrying events disagree on the config hash:

// sla_calc (src/lib.rs, publish_sla_event) — no config_version_hash
(result.outage_id, result.status, result.payment_type, result.rating,
 result.mttr_minutes, result.threshold_minutes, result.amount)

// set_int (publish_settlement_intent_event) — carries it
(..., result.config_version_hash, result.recorded_at)

// dup_input (publish_duplicate_input_event) — carries it
(..., result.config_version_hash, result.recorded_at)

sla_calc is documented as the "Primary event for backend consumers".

Consequences:

  • Consumers of the primary event cannot attribute decisions to config generations: with the duplicate/recalc policy (SC-W5-046), an outage can have multiple sla_calc events across generations; only the events carrying the hash can be grouped, so a consumer subscribing to sla_calc alone cannot reconstruct the generation sequence.
  • The three events' payloads are inconsistent for the same field: the hash is present in two events and absent from the one documented as primary — the payload-redundancy companion issue (different field orders) is compounded by this field-presence divergence.
  • Event-based duplicate detection is impossible: a consumer that replays events to detect conflicting duplicates (the dup_input reconciliation use case) needs the hash on the primary event to match entries across the stream.

Root cause

sla_calc's payload predates the config_version_hash field on SLAResult; set_int and dup_input were written later with the fuller payload, and the primary event was never extended.

Why this is architecturally hard

  1. Adding config_version_hash to sla_calc is an append-only additive change (safe per the event policy — appending to the end of the tuple), but the field order must follow the canonical layout decided by the payload-order companion issue.
  2. The event-size budgets (offchain/eventSizeRegression.ts — companion issue) will need updating if the payload grows; the budgets are currently fiction, so this is an opportunity to make them real.
  3. The change interacts with the "primary event" role: once sla_calc carries the hash, set_int's justification for carrying it (settlement reconciliation) must be re-examined — the events should have one canonical decision payload.

Acceptance criteria

  • sla_calc carries config_version_hash (append-only), and consumers can attribute decisions to generations.
  • All three decision events agree on the shared fields (presence and order).
  • Event-schema docs and the catalog update per the SC-099 checklist.

Out of scope

The payload field-order divergence (companion issue in batch 04) and the set_int missing fields (companion issue in batch 04).

Getting started

just test

Good first files to read: apexchainx_calculator/src/lib.rs (publish_sla_event), apexchainx_calculator/src/event_schema.rs (sla_calc schema).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

GrantFox OSSIssue tracked in GrantFox OSSMaybe RewardedIssue may be eligible for a GrantFox rewardStellar WaveIssues in the Stellar wave programThird CampaignCampaign: Third Campaignarea/eventsImported campaign issue labelpriority/highImported campaign issue label

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions