Saga correlation id loading falls back to expression compilation instead of using the source-generated correlation accessor - #7922
Merged
Conversation
…se them at runtime
danielmarbach
changed the title
danielmarbach
changed the title
danielmarbach
changed the title
danielmarbach
changed the title
Contributor
Author
|
This one #7921 should also go into the patch I think |
DavidBoike
approved these changes
Sep 2, 2026
andreasohlund
approved these changes
Sep 3, 2026
Contributor
Author
|
I realized my notes were incorrect, and I need to backport another commit. I will follow up shortly |
Contributor
Author
|
Here it is #7924 |
danielmarbach
added a commit
that referenced
this pull request
Sep 3, 2026
…7924) Partial backport of cd2db0b (#7918) to release-10.2, complementing the #7922 generator fix. SagaMetadata.Create now forwards the generated correlation accessor to SagaMapper, so correlation ids load through the source-generated accessor instead of runtime expression compilation. The saga source generator parses and emits finder-only sagas with a null correlation accessor, and the AddSaga IL2026 suppressor only suppresses when an interceptor can actually be emitted. The AddMessage<>-related changes of the original commit are intentionally not backported. Co-authored-by: Daniel Marbach <danielmarbach@users.noreply.github.com>
This was referenced Sep 3, 2026
Open
Open
Open
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
3 participants
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.
Backport of c55ef09 to
release-10.2.Symptoms
Saga correlation lookup compiles and invokes an expression tree at runtime on first use per saga type instead of using the source-generated accessor. The generated accessor is discarded before
SagaMapperis built, and the generated code also has issues with the receiver type, duplicate property identities, and setter signatures.Who's affected
Endpoints that map saga correlation to a saga-data property (
mapper.MapSaga(...).ToMessage(...)) and build saga metadata from the source generator, which is the default for saga metadata. The generated path must also distinguish saga-data classes that share a correlation property name and type.Root cause
SagaMetadata.Createaccepts the generated accessor but does not pass it toSagaMapper, so every saga uses the expression-compiled fallback. The generator declaresUnsafeAccessormembers againstIContainSagaDatainstead of the concrete saga-data type, deduplicates accessors by property name and type alone, and emits setters that return the property type instead ofvoid.Confirmed workarounds
No runtime workaround is needed. Correlation loading continues through the expression-compiled fallback, so sagas function as before.
Change
Generate accessors for the concrete saga-data type, key them by saga-data type and property identity, and emit
voidsetters. Tests cover two saga-data classes with the same correlation property name and type.