Resolving recursive contextual binding from IOC container

[flyingL123]

• Laravel Version: 5.8.8
• PHP Version: 7.3.8
• Database Driver & Version: mysql 5.7.27

I have a command class with a dependency type-hinted in the constructor:

class RunAnalyticsCommand extends Command
{
    
    public function __construct(Analytics $analytics)
    {
        //
    }
}

The constructor for the Analytics class looks like this:

class Analytics
{
    public function __construct(Odoo $odoo, ChannelInterface $channel)
    {
        //
    }
}

In a service provider, I've instructed the application what to instantiate for the Odoo class. If I create an instance of Analytics like this, it works fine. It gets the Odoo instance from the container and uses the channel that I pass in.

$analytics = app(Analytics::class, ['channel' => new ChannelA]);

Now, I'm trying to use contextual binding to accomplish all of this "behind the scenes". I write the following in my service provider's register method:

    $this->app->when(RunAnalyticsCommand::class)
        ->needs(Analytics::class)
        ->give(function () {
            return app(Analytics::class, ['channel' => new ChannelA]);
        });

However, now when I run the RunAnalyticsCommand, I get an error that Maximum function nesting level of '256' reached, aborting!

I'm assuming this happens because the give callback is trying to resolve the same Analytics class, and the container treats that call as if it was also coming from the RunAnalyticsCommand class, so it just keeps trying to resolve the same thing over and over.

Is this the expected behavior or a bug with contextual binding? Shouldn't the call to resolve the class from within the give callback not behave as if it were originating from the RunAnalyticsCommand? Is there some other way to tell the container to resolve without using the contextual binding?

[mfn]

Can you try injecting it into handle first?

Arguments to handle are also resolved via the container.

The downside of using the constructor is that it's also resolved when just initializing, e.g. just for ./artisan it already needs to be constructed (so the command can be listed), which can add up in terms of overhead.

[flyingL123]

@mfn I don't think that works though. I was originally injecting into handle, but the class was never getting resolved. I think contexual binding only works in constructors. I have seen that stated in a few places.

Here, for example: #8906

[sisve]

Maximum function nesting level of '256' reached, aborting! is a message from xdebug, you've configured it to break when the call stack reaches 256 frames. Try increasing the limit, or temporarily disable xdebug, and see what message you get. It doesn't have to be a recursive loop, it could just be a deep call stack.

[mfn]

but the class was never getting resolved. I think contexual binding only works in constructors

Oh, sorry; no idea about this.

[flyingL123]

@sisve if I log dump('test') in the give callback I can see it being called over and over again until it fails. Since I'm only trying to resolve this class in one place, it seems like recursion is causing the issue, right?

[flyingL123]

Yea @sisve, I disabled xdebug and ran it again. Now it just calls the give method ~100,000 times and then fails cause it's out of memory.

[mfn]

Maybe you have a cyclic dependency between two of your services, explicit or implicit?

[flyingL123]

I'm not sure what you mean. Isn't the app helper within the give callback simply causing the same callback to be called again? The container thinks that each call to app is origination from the same RunAnalyticsCommand, so it keeps trying to resolve with contextual binding. I don't know if this is intended behavior. It seems like it may not be.

[nmokkenstorm]

Your 'behind the scenes' example does not do what you think it does. Contextual binding is meant to be used in the context of binding concrete instances to interfaces. You're trying to automatically resolve a concrete instance from the service container, and thus creating the cycling dependency @mfn mentions.

First give instructions on how to build your Analytics class, and then tell the container to use that class in the RunAnalyticsCommand. I think the correct code would be

$this->app->bind(RunAnalyticsCommand::class, function () {
    return app(Analytics::class, ['channel' => new ChannelA])
})

$this->app->when(RunAnalyticsCommand::class)
    ->needs(AnalyticsInterface::class)
    ->give(function () {
        return app(Analytics::class);
    });

Alternatively, you could manually construct the Analytics class in the first callback, and bind that as an instance.

[driesvints]

@flyingL123 can you try the example from @nmokkenstorm?

[driesvints]

Closing this issue because it's inactive, already solved, old or not relevant anymore. Feel free to reply if you're still experiencing this issue and we'll re-open this issue.