Adopt JasperFx 2.37.3 - #5129
Merged
Merged
Conversation
#611: JasperFx.Events.SourceGenerator now discovers an EventProjection's published document types semantically rather than syntactically. Discovery previously matched only GenericNameSyntax, so an explicit ApplyAsync override writing operations.Store<AuditRecord>(record); registered AuditRecord while the equally valid operations.Store(record); compiled and registered nothing at all. Nothing at the call site says so and nothing fails at runtime -- storage is provisioned on demand -- so only the ahead-of-time surfaces came up short: schema creation, AllKnownDocumentTypes, rebuild teardown. This is the same marten#4166 behaviour, now correct for both spellings. Behaviour-changing for the better, and worth a release note: an ApplyAsync override using the non-generic spelling starts registering document types it silently skipped before. Also carried: Store<object>(...) no longer registers `object` itself as a document type (object/string render through ToDisplayString() as C# keywords and slipped past the old name-prefix check), and a new JFXEVT005 Info diagnostic for a call that binds to the projection's session but whose document type cannot be named. net9.0: EventSourcingTests 1614/0/7, DaemonTests 260/0/0. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VpDCvJcBDZerieJB4JEHde
This was referenced Aug 4, 2026
29 tasks
This was referenced Aug 5, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Picks up JasperFx/jasperfx#611, which is the reason 2.37.3 exists.
What changes for Marten users
JasperFx.Events.SourceGeneratornow discovers an EventProjection's published document types semantically rather than syntactically. Discovery used to match onlyGenericNameSyntax, so inside an explicitApplyAsyncoverride:Nothing at the call site says so, and nothing fails at runtime — storage is provisioned on demand — so only the ahead-of-time surfaces came up short: schema creation,
AllKnownDocumentTypes(), rebuild teardown. Same #4166 behaviour, now correct for both spellings.This is behaviour-changing, in the good direction, and belongs in the release notes. A projection using the non-generic spelling will start registering document types it silently skipped before. The visible effects are that those types now appear in
AllKnownDocumentTypes()and get their storage created up front.Also carried:
Store<object>(...)no longer registersobjectitself as a document type.objectandstringrender throughToDisplayString()as their C# keywords, notSystem.Object/System.String, so they slipped past the old name-prefix check; registrability is now aSpecialType/TypeKindquestion.object,dynamic, an open type parameter. Info rather than Warning so it cannot break aTreatWarningsAsErrorsbuild over a legitimate call.Verification
net9.0, against the published packages:
EventSourcingTests1614 / 0 / 7DaemonTests260 / 0 / 0One transient
DaemonTestsfailure appeared on the first of three runs and I could not identify it — the run output was not captured, and two subsequent full runs were clean at 260/0/0. Recording it rather than omitting it; I have no evidence tying it to this bump, and a registration change would present deterministically rather than intermittently.🤖 Generated with Claude Code
https://claude.ai/code/session_01VpDCvJcBDZerieJB4JEHde