filamentphp
Filament V3 Notification Rendered Twice if Livewire Event is Fired in Child Component
Package
filament/filament
Package Version
3.3.28
Laravel Version
12.19.3
Livewire Version
3.6.3
PHP Version
8.4.8
Problem description
For a Filament Panel Page that includes a child Livewire component, a Filament Notification fired by that child component is rendered twice by Filament's notifications.blade.php if a Livewire event is fired at the same time. If an event is not fired, the notification renders only once.
Expected behavior
The Filament Notification blade should be rendered only once for any call to the Notification object.
Steps to reproduce
Given the provided repo.
composer install
php artisan migrate
php artisan make:filament-user
In vendor/filament/notifications/resources/views/notifications.blade.php log out the $notifications variable:
@php
use Filament\Support\Enums\Alignment;
use Filament\Support\Enums\VerticalAlignment;
\Log::info($notifications);
@endphp
Navigate to /admin/foobar .
Click "With Event" button. Refresh.
Click "Without Event" button. Refresh.
Checking laravel.log, the "With Event" log is proceeded by two renders of a notification with the same ID. The "Notification without Event" is proceeded by just one.
(See log output below)
Reproduction repository (issue will be closed if this is not valid)
https://github.com/jasonlund/filament-notification
Relevant log output
[2025-06-23 16:36:13] local.INFO: []
[2025-06-23 16:36:42] local.INFO: []
[2025-06-23 16:36:43] local.INFO: Notification with Event
[2025-06-23 16:36:43] local.INFO: {"9f3994ea-cbdd-429b-9202-1c2aa6582117":{"id":"9f3994ea-cbdd-429b-9202-1c2aa6582117","actions":[],"body":null,"color":null,"duration":6000,"icon":"heroicon-o-check-circle","iconColor":"success","status":"success","title":"With Event","view":"filament-notifications::notification","viewData":[]}}
[2025-06-23 16:36:43] local.INFO: {"9f3994ea-cbdd-429b-9202-1c2aa6582117":{"id":"9f3994ea-cbdd-429b-9202-1c2aa6582117","actions":[],"body":null,"color":null,"duration":6000,"icon":"heroicon-o-check-circle","iconColor":"success","status":"success","title":"With Event","view":"filament-notifications::notification","viewData":[]}}
[2025-06-23 16:36:44] local.INFO: []
[2025-06-23 16:36:46] local.INFO: Notification without Event
[2025-06-23 16:36:46] local.INFO: {"9f3994ee-65f6-434d-95b4-e1c266b15e85":{"id":"9f3994ee-65f6-434d-95b4-e1c266b15e85","actions":[],"body":null,"color":null,"duration":6000,"icon":"heroicon-o-check-circle","iconColor":"success","status":"success","title":"Without Event","view":"filament-notifications::notification","viewData":[]}}
[2025-06-23 16:36:52] local.INFO: []
I know what the problem is, but I don't know to fix it really.
Before a Livewire request is returned, we check if there are any notifications that are due to be sent in the session. This all happens in NotificationServiceProvider. Each component has this check, and when an event is dispatched from the same request as the one that sent notifications, it causes both dispatches to be batched into one request. If the component that listens to the dispatch is processed first, it attempts to send the notifications again, since the notifications haven't been sent by that point yet, as the notifications component is processed after.
@danharrin
Thanks for looking at this. I'm sure you're busy enough with V4.
Funnily enough I got a chance to deep dive this on Friday and came to the same root cause as you. The best fix I could find is to use the request fingerprint and checking that during the request lifecycle to avoid 'notificationsSent' to be dispatched more than once.
You can find my PR at #17056 .
Meant to update this a few months ago. We never found a solution for this. Instead we off loaded the notifications to broadcast which effectively went around this bug.
The PR above was not a proper solution.
This is still an active bug as far as I'm aware. No known solution.