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

Add a resolved/compatible service parameter to decorator resolutions. #1424

Merged
merged 1 commit into from
Sep 2, 2024

Conversation

tillig
Copy link
Member

@tillig tillig commented Aug 14, 2024

Resolves #1330.

When...

  • An open generic is registered and exposes two services (IServiceA and IServiceB).
  • An open generic decorator is registered against one of those services (IServiceB).
  • The open generic is resolved against the other service (IServiceA).

...then, while the underlying component should be decorated, when the decorator is created it sees that "the wrong service" is being resolved so it, instead, attempts to execute a separate resolution operation. This can result in resolving the wrong type.

The solution proposed here adds both a TypedParameter (for "exact match" support, used by lambda-registered decorators and ensuring backwards-compatibility with existing code) and a ResolvedParameter. The new ResolvedParameter checks to see if the target decorator parameter is type compatible instead of type equal so the instance being decorated will end up getting used.

This does open up a potential edge case bug where a decorator could technically take both an IServiceA and an IServiceB and the new behavior will use the decorated instance as both parameters instead of using it for one parameter and resolving the other from the container.

If we could reverse-lookup the service being resolved back to the original component and then enumerate all of the exposed services from there, it would be a more 100% precise match, but it would also be a bit more expensive and, given the time I had, I couldn't figure out how to do that. :)

The failing test here is added directly from #1330.

@tillig tillig requested a review from alistairjevans August 14, 2024 21:53
Copy link

codecov bot commented Aug 14, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 78.60%. Comparing base (488294e) to head (caa3e04).
Report is 4 commits behind head on develop.

Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #1424      +/-   ##
===========================================
+ Coverage    78.58%   78.60%   +0.01%     
===========================================
  Files          200      200              
  Lines         5716     5720       +4     
  Branches      1168     1168              
===========================================
+ Hits          4492     4496       +4     
  Misses         712      712              
  Partials       512      512              

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

Copy link
Member

@alistairjevans alistairjevans left a comment

Choose a reason for hiding this comment

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

Looks good; this decorator stuff only gets more complicated! 😂

@tillig tillig merged commit 4059546 into develop Sep 2, 2024
4 checks passed
@tillig tillig deleted the feature/generic-decorator branch September 2, 2024 00:30
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.

[Autofac 6.4.0]: RegisterGenericDecorator() resolves incorrect instance for the decorated type
2 participants