[kayw-geek]

Fixes a name-based parameter resolution issue introduced in #60144.

Background

#60144 made it possible to pass the scheduled Event into lifecycle callbacks, and the PR description promises that you can "typehint a callback with Event $event as a parameter". However, the implementation only injects the event when the closure parameter is literally named $event. The is_a($this, $eventParameterType) check in the same method shows the intent was type-based, but the lookup is name-based — these contradict each other.

All tests added by #60144 happen to use the parameter name $event, so the working contract (typehint-based) was never exercised.

Reproduction

Schedule::command('inspire')
    ->before(function (Event $scheduledEvent) {
        Log::info("Starting {$scheduledEvent->command}");
    });

This throws BindingResolutionException: the parameter lookup misses on the name 'event', no value is injected, and the container falls back to autowiring a new Event — which fails because EventMutex isn't instantiable.

Fix

Iterate the closure parameters and inject $this into the first parameter whose type is a class that $this is an instance of. This matches how Laravel container DI works elsewhere — by type, not by name.

After

Schedule::command('inspire')
    ->before(function (Event $scheduledEvent) {  // works
        Log::info("Starting {$scheduledEvent->command}");
    });

Schedule::command('inspire')
    ->before(function (Event $event) {  // still works
        Log::info("Starting {$event->command}");
    });

[kayw-geek]

array_any returns bool though, so $event would just be true/false — $name from the closure isn't in scope either. Did you mean array_find_key?

Either way I'd lean toward keeping the foreach — the other 3 spots using closureParameterTypes() in this file all do the same $parameters = ...; foreach thing.

[shaedrich]

Yeah, sorry–my bad 🤦🏻 😅