Ensure that ObjectExecutorFactory
resolves the handler that was used to generate metadata
#639
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.
Previously, the
ObjectExecutorFactory
resolvedIXHandler<A>
directly from the container. The problem with that approach is that we can't be sure that theTypeAssembly
that we get inCQRSObjectsRegistrationSource.AddCQRSObjects
represents all the assemblies that the user scanned for handlers when adding them to DI. For example, it is still possible to have this:Then in
App
have:which would result, in the end, in (effectively, the code will be slightly different):
But the
CQRSObjectsRegistrationSource.objects
will have only theCommand, CH1
pair. Thus, the pipeline will think that it executesCH1
, butCH2
will be resolved inObjectExecutorFactory.ExecuteCommandAsync
.I admit that this is rather unlikely situation, but when it occurs, it might be very hard to detect. I also don't think this PR makes detection easier, but at least it will resolve
CH1
when it thinks aboutCH1
. This might be more important for local execution though.