Problem
src/event.rs — the module that claims "Events are always published through this struct to ensure consistent topic layout" — uses a 2-topic layout:
// src/event.rs, EventPublisher::publish_calculation_executed
env.events().publish((topic, input_key), payload);
Every emitted event follows the documented 3-topic convention (name, version, context — see src/event_schema.rs): (EVENT_SLA_CALC, EVENT_VERSION, severity). The dead EventPublisher (companion issue) publishes (topic, input_key) — no version topic.
Consequences:
- The documented convention and the "canonical" publisher disagree: if a contributor wired the contract to use
EventPublisher (the module's stated role), every event it emitted would have 2 topics, breaking indexers that parse the 3-topic schema (topic[1] = version) — the exact consistency the module promises.
CalculationExecutedEventV1's payload shape also matches nothing emitted (companion issue): the dead publisher is wrong on both topics and payload, making it a misleading reference implementation.- The versioning protocol is bypassable by accident: the 3-topic layout exists so event versions are always present in topic[1]; a 2-topic emit silently drops versioning from those events.
Root cause
EventPublisher was authored before the 3-topic convention was standardized and never updated (it is unwired, so the mismatch is invisible to tests).
Why this is architecturally hard
- The fix depends on the EventPublisher decision (companion issue): if the module is kept and wired,
publish_calculation_executed must emit (name, EVENT_VERSION, context) and the CalculationExecutedEventV1 struct must be replaced by the real tuple payloads; if it is deleted, the topic-layout authority moves fully to event_schema.rs.
- The 3-topic layout is enforced by convention and tests (topic-stability tests), not by the SDK — a 2-topic emit compiles fine, so only a test that asserts topic arity per event would catch the class.
- The issue should add (or extend) a test asserting every published event has the documented topic arity, so the convention is mechanical, not memorial.
Acceptance criteria
Out of scope
The EventPublisher dead-code resolution (companion issue) and the payload field-order divergence (companion issue).
Getting started
Good first files to read: apexchainx_calculator/src/event.rs, apexchainx_calculator/src/event_schema.rs (topic layout), apexchainx_calculator/src/topic_stability_tests.rs.
Problem
src/event.rs— the module that claims "Events are always published through this struct to ensure consistent topic layout" — uses a 2-topic layout:Every emitted event follows the documented 3-topic convention (name, version, context — see
src/event_schema.rs):(EVENT_SLA_CALC, EVENT_VERSION, severity). The deadEventPublisher(companion issue) publishes(topic, input_key)— no version topic.Consequences:
EventPublisher(the module's stated role), every event it emitted would have 2 topics, breaking indexers that parse the 3-topic schema (topic[1]= version) — the exact consistency the module promises.CalculationExecutedEventV1's payload shape also matches nothing emitted (companion issue): the dead publisher is wrong on both topics and payload, making it a misleading reference implementation.Root cause
EventPublisherwas authored before the 3-topic convention was standardized and never updated (it is unwired, so the mismatch is invisible to tests).Why this is architecturally hard
publish_calculation_executedmust emit(name, EVENT_VERSION, context)and theCalculationExecutedEventV1struct must be replaced by the real tuple payloads; if it is deleted, the topic-layout authority moves fully toevent_schema.rs.Acceptance criteria
EventPublisher(if kept) emits the documented 3-topic layout with real payload shapes, or the module is removed.Out of scope
The EventPublisher dead-code resolution (companion issue) and the payload field-order divergence (companion issue).
Getting started
just testGood first files to read:
apexchainx_calculator/src/event.rs,apexchainx_calculator/src/event_schema.rs(topic layout),apexchainx_calculator/src/topic_stability_tests.rs.