Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure that ObjectExecutorFactory resolves the handler that was used to generate metadata #639

Merged
merged 3 commits into from
Feb 7, 2024

Conversation

jakubfijalkowski
Copy link
Member

Previously, the ObjectExecutorFactory resolved IXHandler<A> directly from the container. The problem with that approach is that we can't be sure that the TypeAssembly that we get in CQRSObjectsRegistrationSource.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:

Contracts.csproj
   - Command : ICommand

HandlersA.csproj
  - CH1: ICommandHandler<Command>

HandlersB.csproj
  - CH2: ICommandHandler<Command>

Then in App have:

serviceCollection
    .AddCQRS(TypesAssembly.Of<Command>(), TypesAssembly.Of<CH1>())
    .AddCQRSObjects(TypesAssembly.Of<Command>(), TypesAssembly.Of<CH2>());

which would result, in the end, in (effectively, the code will be slightly different):

serviceCollection.AddTransient<ICommandHandler<Command>, CH1>();
serviceCollection.AddTransient<ICommandHandler<Command>, CH2>();

But the CQRSObjectsRegistrationSource.objects will have only the Command, CH1 pair. Thus, the pipeline will think that it executes CH1, but CH2 will be resolved in ObjectExecutorFactory.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 about CH1. This might be more important for local execution though.

Copy link

github-actions bot commented Feb 6, 2024

Test Results

 35 files  ±0  120 suites  ±0   1m 5s ⏱️ -2s
662 tests +3  649 ✅ +3  13 💤 ±0  0 ❌ ±0 
678 runs  +3  658 ✅ +3  20 💤 ±0  0 ❌ ±0 

Results for commit 03011ef. ± Comparison against base commit 2b28316.

♻️ This comment has been updated with latest results.

Copy link

codecov bot commented Feb 6, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (2b28316) 64.02% compared to head (628e4c3) 64.02%.

❗ Current head 628e4c3 differs from pull request most recent head 03011ef. Consider uploading reports for the commit 03011ef to get more accurate results

Additional details and impacted files
@@           Coverage Diff           @@
##             v8.0     #639   +/-   ##
=======================================
  Coverage   64.02%   64.02%           
=======================================
  Files         245      245           
  Lines        5823     5824    +1     
  Branches      376      376           
=======================================
+ Hits         3728     3729    +1     
  Misses       1986     1986           
  Partials      109      109           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Member

@marcin-dardzinski marcin-dardzinski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

serviceCollection
    .AddCQRS(TypesAssembly.Of<Command>(), TypesAssembly.Of<CH1>())
    .AddCQRSObjects(TypesAssembly.Of<Command>(), TypesAssembly.Of<CH2>());

Interesting corner case, shouldn't CQRSObjectsRegistrationSource throw on such cases. If I register command with two handlers there's clearly sth wrong.

@jakubfijalkowski
Copy link
Member Author

Interesting corner case, shouldn't CQRSObjectsRegistrationSource throw on such cases.

It probably should, but it won't solve the problem - the user will still be able to overcome that with two calls to the AddCQRS or manual AddTransient<ICommandHandler<Command>, CH2>().

@jakubfijalkowski jakubfijalkowski changed the base branch from v8.0 to v8.1-preview February 7, 2024 09:38
@jakubfijalkowski jakubfijalkowski merged commit 4bdf32c into v8.1-preview Feb 7, 2024
7 checks passed
@jakubfijalkowski jakubfijalkowski deleted the fix/handler-resolving branch February 7, 2024 09:45
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.

2 participants