`SendEmailVerificationNotification` gets invoked multiple times

[orkhanahmadov]

Laravel Version

11.1.0

PHP Version

8.3

Database Driver & Version

No response

Description

When the User model uses the MustVerifyEmail interface, on new registration \Illuminate\Auth\Listeners\SendEmailVerificationNotification gets invoked multiple times. Started happening on v11, did have this issue on v10.

Steps To Reproduce

• Implement MustVerifyEmail on the User model.
• Sign up as a new user
• User will receive the same verification email multiple times

[orkhanahmadov]

Another easy way to produce:

• Set email_verified_at null on existing $user
• Run:

event(new \Illuminate\Auth\Events\Registered($user));

[yourchocomate]

Can you provide more information? It seems okay on my side.

[crynobone]

Hi there,

Thanks for reporting the problem you are encountering, but it looks like this is a question which may be better suited for a support channel. We only use this issue tracker for reporting bugs with the library itself. If you have a question on how to use functionality provided by this repository you can try one of the following channels:

• Laracasts Forums
• Laravel.io Forums
• StackOverflow
• Discord
• Larachat
• IRC

However, this issue will not be locked and everyone is still free to discuss solutions to your problem!

Thanks.

[danielDigitalArt]

Hi,

i got the same problem. sendEmailVerificationNotification is called 4 Times for me, it is a laravel installation which i updated recently from Laravel 8 to 11 (step by step, following the update Guides).

I tried to find the source of it and could find that the Event Illuminate\Auth\Events\Registered has exactly 4 Listeners, while other events seem to have mostly 1 Listener if any.

When i tried to find out what Class these Listeners are i only found out that these are Closures, Debugging these gave me this Code:

function ($event, $payload){
            if ($wildcard) {
                return call_user_func($this->createClassCallable($listener), $event, $payload);
            }

            $callable = $this->createClassCallable($listener);

            return $callable(...array_values($payload));
        };

This Code comes from the Dispatcher itself:
public function createClassListener($listener, $wildcard = false)

I also found a listener which was registered on this Event by the "app/Providers/EventServiceProvider" Class, i removed the registration but it had no difference in the number of registered Listeners on this event.
As my installation also runs with a queue i tried to restart all workers, as well as running php artisan event:clear and php artisan event:cache but that did not change anything.

Laravel: 11.4.0
PHP: 8.2

Edit:
After debugging in the Dispatcher function createClassListener it shows that the Listener is the Class Illuminate\Auth\Listeners\SendEmailVerificationNotification but i still do not know why it would be registered 4 times for this Event.

[orkhanahmadov]

@danielDigitalArt Hi,

We investigated a bit and found out that in our case issue was caused by using many service providers that extend Laravel's event service provider. We use domain pattern where each domain has its Event service provider. Each added event service provider basically executes the listener on the Registered event because it is defined by Laravel's event service provider, here: https://github.com/laravel/framework/blob/11.x/src/Illuminate/Foundation/Support/Providers/EventServiceProvider.php#L207-L213

Unfortunately, Laravel team added that listener without considering that some applications might use more than one event service provider. I think there's no clean way to solve it anymore without removing that code and causing a breaking change.

In our case, we were using a Registered event to execute certain listeners of our own, we instead created a new Event and used that.

Alternative solutions would be overwriting configureEmailVerification() on your event service provider and leaving it empty.

Or alternatively, I just proposed this change to optionally turn off that listener when needed.

[danielDigitalArt]

@orkhanahmadov
Thank you for your reply, this gave me the info that i needed.
I had laravel-modules installed and 3 Modules in total, each registered some events by extending the default EventServiceprovider. So for each Module the configureEmailVerification function was executed, which adds another eventlistener.

My solution was to define an abstract class which unsets the function like so:

namespace App\Modules;

use Illuminate\Foundation\Support\Providers\EventServiceProvider as ServiceProvider;

class AbstractModuleEventServiceProvider extends ServiceProvider{
    protected function configureEmailVerification(){
        
    }
}

Then each Eventserviceprovider in the modules has to extend from this abstract class.

[adiachenko]

This should not be dismissed as a user issue imo.

We have 5 packages in our project (some from third parties) that use EventServiceProvider to register their own events and with each implicitly calling configureEmailVerification in Laravel 11 users receive 5 email verification notification.

@taylorotwell Extending EmailServiceProvider is a very common pattern so I kindly ask that this is at least mentioned in Laravel 11 upgrade guide if you think that addressing this at a framework level is too unreasonable of an ask.