Releases: jamesmills/laravel-notification-rate-limit
Releases · jamesmills/laravel-notification-rate-limit
3.1.1
3.1.0
- Fixed: If an exception occurs within the rate limiter implementation, it will be logged and reported but we try to continue sending the notification itself (irrespective of any rate limit that might have applied). This avoids the possibility of silently causing notifications to not be dispatched at all.
- New: Added config option
unique_notification_strategy
to allow choosing the mechanism to use when determining whether a notification is unique (in caseserialize()
is not appropriate).
3.0.0
What's Changed
- Expanded the
NotificationRateLimitReached
event to directly expose additional information about the notification being discarded (including the relatedNotifiable
object, the cache key, the time remaining until the limiter will be available again, and the reason for the discard) - Added the ability for a notification to trigger a discard/bypass for reasons other than the rate limiter being hit (see issue #37)
2.2.0
2.1.0
- Fixed Issue #14: Rate limiting will now be checked when notifications are actually being dispatched from the queue, rather than when they are queued up (allowing rate limiting to work against notifications having an associated delay)
- Updated README.md to caution regarding the rate limiting keys for applications that may include multiple types of
Notifiable
entities
2.0.0
- Add support for Laravel 9.x/10.x
- Remove support for PHP 7.x/Laravel 7.x/8.x
- Fixed Issue #17: Anonymous notifications can now be rate-limited
- Fixed: The rate limiter now works with multi-recipient notifications sent via the
Notification::send()
facade - New: You can now define a
rateLimitNotifiableKey()
method on aNotifiable
object to override the value that will be used to identify that object as unique (by default, the primary key orid
field)
1.0.1
Merge pull request #11 from TAGHREEDAA/fix-notification-sent-before-s…