Skip to content

Release v16.38.0

Choose a tag to compare

View all tags
@github-actions github-actions released this 23 Aug 18:30
v16.38.0
e83a194
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Summary

Marking a previous generation of an event type today means giving it its own [EventType(id, generation)] with an id that must exactly match the current generation's id, by hand. Get that wrong - omit the id (it silently defaults to the CLR type name) or typo it - and Chronicle treats the two generations as completely unrelated event types. The migration never applies, and registration can fail later with a confusing EventTypeSchemaChanged error that gives no hint the real problem is a mismatched id.

This PR introduces EventTypeGenerationFor<TEventType>, which resolves a previous generation's event type id directly from the current generation's own [EventType] attribute instead of a hand-typed, easy-to-mismatch string, plus the compile-time and runtime checks needed to catch misuse of both the new and the older style early.

While implementing this, a second and independent cause of the same symptom was found and fixed: event type registration could non-deterministically send an empty placeholder schema instead of a real one, purely due to dictionary enumeration order - unrelated to whether the ids matched.

Added

  • EventTypeGenerationFor<TEventType> attribute for declaring a previous generation of an event type - the event type id is resolved from the referenced current-generation type, so it can never drift from it (#3815)
  • Roslyn analyzers CHR0049 and CHR0050, validating that EventTypeGenerationFor<T>'s referenced type is itself a valid, directly-marked [EventType], and that a type never carries both attributes at once (#3815)
  • Runtime checks that fail loudly at event type registration: an EventTypeMigration<TUpgrade, TPrevious> whose two generations resolve to different event type ids, or two migrators that both bridge the same generation pair for one event type (#3815, #3816)

Changed

  • CHR0037 now also validates migrations that use EventTypeGenerationFor<T> (checking it points at the migration's own upgrade type), instead of silently no longer checking anything the moment a migration doesn't use the older explicit-id style (#3815)
  • An EventTypeMigration<TUpgrade, TPrevious> whose two generations resolve to different event type ids now throws at startup instead of registering successfully and failing later, or silently registering an incorrect schema. Any application already relying on the old mismatched-id pattern was already non-functional against a production Chronicle kernel; this surfaces that failure immediately and clearly instead of downstream as EventTypeSchemaChanged (#3816)

Fixed

  • Fixed event type registration sending an empty placeholder schema for a generation instead of its real schema, non-deterministically, depending on dictionary enumeration order - independent of whether the generations' ids matched (#3816)
Assets 2
Loading