-
Notifications
You must be signed in to change notification settings - Fork 11.2k
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
Container having trouble resolving services: interface + binding for concrete class #31588
Comments
Hey there, Can you first please try one of the support channels below? If you can actually identify this as a bug, feel free to report back and I'll gladly help you out and re-open this issue. Thanks! |
@driesvints i went to IRC channel and asked for advice, as you suggested, just in case. We could not find a working solution and someone even mentioned:
I think it might be worthwhile to look into this issue. Please let me know what you think. |
You're not binding the scalar dependency here with binding a primitive: https://github.com/rkazaniszyn/laravel-deferred-providers-bug/blob/master/app/Providers/SampleInterfaceProvider.php#L19 |
Yes i know, i did it on purpose to illustrate the problem. Primitive binding isn't there, because this provider only provides SampleInterface, not the concrete implementation of this interface. Reasons why i reported this and got back to you:
Looks like this change might be the case: d0a7adb#diff-52441e04e14c52275cd5d09e8f958981L264 |
I think it is indeed a bug. It also worked for me in 5.7 and stopped working in 5.8. Moreover, if you try to inject implementation first and then interface, it works. If you switch order and want to inject something by interface first, it does not work. Containter behaves different depending on order of resolved classes, which is even more dangerous, because it "sometimes" works and could be easily missed while testing. The problem is probably caused by this line: In 5.7 it used Reverting this line to state from 5.7 ( |
Something that worked till 5.7 and stoped worked on 5.8 (without mention anywhere) looks like bug to me. |
This PR brings back behaviour from Laravel 5.7 when you could use deferred provides to bind an interface to implementation even when implementation had its own deferred provider. Changing `resolve` method to `make` results in calling `Illuminate\Foundation\Application::make` method which loads deferred providers. Calling `resolve` method calls `Illuminate\Container\Container::resolve` which does not load deferred providers. PR is the effect of discussion in laravel#31588
Submit a PR with a failing test to prove it is a bug in the container. |
Description:
Hi there,
In some circumstances, for some reason, container is having problem with resolving services.
If a service (concrete) implements an interface (abstract) and this service (concrete) requires additional service provider (e.g. when value from config is injected to class), you may end up with
Unresolvable dependency resolving error
. It happens when both binding abstract interface to concrete class and injecting dependencies is split between two deferred service providers.Interesting part: automatic injection of such interface works for console commands, but does not work for controllers (not sure, but there might be more contexts affected)
Steps To Reproduce:
composer install
php artisan command:test
# It should work finephp artisan serve
do a request to "/test" endpoint # Ends up with HTTP 500; logs contain "Unresolvable dependency resolving" errorThe text was updated successfully, but these errors were encountered: