Add a resolved/compatible service parameter to decorator resolutions. #1424
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.
Resolves #1330.
When...
IServiceA
andIServiceB
).IServiceB
).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 aResolvedParameter
. The newResolvedParameter
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 anIServiceB
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.