Skip to content

feat(events): add event schema versioning with compatibility rules (#1805) - #1830

Open
nissinanlung wants to merge 1 commit into
Smartdevs17:mainfrom
nissinanlung:fix/issue-1805-event-schema-versioning
Open

nissinanlung wants to merge 1 commit into
Smartdevs17:mainfrom
nissinanlung:fix/issue-1805-event-schema-versioning

Conversation

@nissinanlung

Copy link
Copy Markdown
Contributor

Summary

Closes #1805.

Event consumers break when producers change payload shapes. This adds a versioned schema registry that classifies every change as backward / forward / full / none compatible and migrates payloads across versions, making breakage an explicit, reviewable decision.

Changes

  • backend/shared/events/schemaVersioning.ts — SchemaVersionRegistry (multi-version registration), diffSchemas (structured FieldChange diff + compatibility classification), validateAgainstVersion, registerMigrator + migrate (auto default-filling + explicit migrator chains).
  • backend/shared/events/__tests__/schemaVersioning.test.ts — 20+ tests covering every compatibility rule, validation, and migration chains.
  • docs/EVENT_SCHEMA_VERSIONING.md — compatibility levels, rules, usage examples, integration with the existing event catalog.

Compatibility rules

Change Level
Add optional field full
Add required field with default full
Add required field without default forward
Remove optional field full
Remove required field backward
Change field type none (breaking)
Optional → required (no default) breaks backward
Required → optional breaks forward

Acceptance criteria

  • Versioned — SchemaVersionRegistry stores arbitrary versions per event type (getVersion/getLatestVersion/getVersions).
  • Compatibility tested — 20+ tests classify every change rule and exercise migration chains.
  • Documented — docs/EVENT_SCHEMA_VERSIONING.md with rules and examples.

Quality Gates

  • Lint / Prettier
  • TypeScript types
  • Tests added
  • Documentation updated

…martdevs17#1805)

Add a versioned schema registry that classifies payload-shape changes as
backward / forward / full / none compatible and migrates payloads across
versions, preventing silent consumer breakage when event producers evolve.

Changes:
- Create backend/shared/events/schemaVersioning.ts: SchemaVersionRegistry
  with multi-version registration, diffSchemas (structured FieldChange diff
  + compatibility classification), validateAgainstVersion, registerMigrator
  and migrate (auto default-filling + explicit migrator chains)
- Create backend/shared/events/__tests__/schemaVersioning.test.ts: 20+ test
  cases covering every compatibility rule, validation, and migration chains
- Create docs/EVENT_SCHEMA_VERSIONING.md: compatibility levels, rules,
  usage examples, integration with the existing event catalog

Acceptance criteria:
- [x] Versioned — SchemaVersionRegistry stores arbitrary versions per event
      type with getVersion/getLatestVersion/getVersions
- [x] Compatibility tested — 20+ tests classify every change rule and
      exercise migration chains
- [x] Documented — docs/EVENT_SCHEMA_VERSIONING.md with rules and examples
@drips-wave

drips-wave Bot commented Oct 18, 2026

Copy link
Copy Markdown

@nissinanlung Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

@nissinanlung
nissinanlung deployed to security-review October 18, 2026 21:14 — with GitHub Actions Active

This branch was successfully deployed

1 active deployment
security-review — 5b2b215a Deployed Oct 18, 2026 by nissinanlung via Security Dashboard #1382
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add event schema versioning

1 participant