IxDF Developer Docs

Appearance

Tips on updating notification classes ​

Understanding delayed delivery ​

Notifications may not be delivered immediately after being queued. Take, for example, the App\Notifications\Membership\Renewal\MembershipExpired notification, which makes use of the Delayable trait. This notification will only be sent between Tuesday and Thursday:

php
use App\Modules\Membership\Models\IndividualMembership;use App\Notifications\Support\Delayable;use App\Notifications\Support\Mail\MailNotification;use App\Notifications\Support\ShouldDelay;

final class MembershipExpired extends MailNotification implements ShouldDelay
{
    use Delayable;

    public function __construct(IndividualMembership $membership)
    {
        $this->setDayOfWeek(ShouldDelay::TUESDAY_TO_THURSDAY);

        ...
    }

This mechanism improves the deliverability of specific notifications. However, it's important to note that notifications queued on a Friday will remain in the queue for several days until they are finally sent the following Tuesday.

Additionally, notifications that are part of notification chains are scheduled for future delivery. The start_processing_after attribute of NotificationChainStatus provides insight into when the next notification in the chain will be sent.

Pitfalls of modifying notification classes ​

When making changes to notification classes, it's crucial to remember that the queue may contain existing notifications. Certain changes may potentially disrupt these queued notifications. Please exercise caution when implementing modifications such as:

  • Changing the class name
  • Changing the class namespace
  • Adding or updating class properties

If you add a new property to a class but have old instances of that class stored in a queue, the property won't be initialized. It doesn't matter if the property is a constructor parameter or not.

Tips on updating notification classes safely ​

There isn't one bullet-proof solution, but there are a few strategies that can be followed to limit the risk of disrupting queued notifications.

Keep new and old implementation of a notification for a period of time ​

If in doubt whether a change to a notification class will disrupt existing queued notifications, it is recommended to keep the old implementation of the notification intact until the queue of "old" notifications is processed and emptied.

Bring notification logs up to date ​

The notification system relies on the notification logs to enforce frequency limits. Therefore, if the class name or namespace has been modified, ensure that the notification logs are updated accordingly to reference the correct classes:

  • Notification logs (see notification_class column in notification__notification_log table)
  • Notification chain status (see chain_class column in notification__notification_chain_status table)

Update notification chain context ​

When making a notification chain contextual by modifying it to extend ContextualNotificationChain class, consider updating the existing notification chains to have the right context. See context_type and context_id columns in the notification__notification_chain_status table. Failure to update the context will result in an error when executing the NotificationChain::execute method, with the following message:

text
 Unable to process NotificationChainStatus#X. No context found! The `XX` Notification is contextual (means the $context Model is required), but NotificationChainStatus record does not contain any context.

By following these tips and best practices, you can confidently update notification classes while maintaining the integrity of the notification system.

Considerations for the future ​

  1. Consider using class_alias when updating the namespace.
  2. Laravel queues work by serializing and unserializing PHP objects, enabling us to leverage the potential of magic: