Skip to content

Version the contract event schema before integrators depend on it #78

Description

@joelpeace48-cell

Problem

Events are a public interface. Once an indexer, an export pipeline, or a partner
consumes them, changing a topic or reordering a data tuple silently breaks
downstream consumers — and unlike an entrypoint signature, there is no
compile-time error to catch it.

What to do

  • Include a schema version in every event's topic tuple from the start.
  • Document the full event catalogue: name, topics, data layout, and which
    entrypoint emits it.
  • Establish the compatibility rule — additive changes only within a version;
    anything else increments it and both are emitted during a migration window.
  • Add tests asserting exact event shape, so a change is a visible test failure
    rather than a silent break.
  • Generate the catalogue from code where possible.

Acceptance criteria

  • Version in every event topic tuple
  • Event catalogue documented and generated
  • Compatibility policy written down
  • Shape assertions in tests

Notes

Cheap now, expensive later. Adding a version field before anyone consumes
events costs nothing; adding one afterwards is itself the breaking change.

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    GrantFox OSSIssue tracked in GrantFox OSSThird CampaignCampaign: Third Campaignarea:workspaceWorkspace, build, releasedifficulty:mediumFamiliar patterns; touches a few files or conceptspriority:highNeeded for the next milestonetype:choreTooling, CI, dependencies

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions