Accessing the a job's payload from a mailable

[ju5t]

Use case

We want to keep an audit log of who sends an e-mail or starts a job. A log entry would look like this:

Quote was sent by e-mail to [email protected] by username.

There is a different log entry when there's an exception. This is pretty straightforward when you're not queueing e-mails. It's not when you're queueing them. Ideally, we want to keep the responsibility of completed jobs with the job and e-mail, as failed does now.

The problem

Queueing an e-mail means it gets wrapped in a SendQueuedMailable job. This results in two different problems for us.

1. We do not have access to the handle method to log a successfully sent e-mail.
2. We do not have access to the job payload, so we cannot fetch the user id from it.

Note: we're injecting the user id into the payload with Queue::createPayloadUsing; see: Injecting Additional Data into Laravel Queued Jobs.

We do not prefer to naively mark the e-mail as sent when it's queued and mark it as failed when an exception occurs.

Workarounds

You could argue that sending e-mails should be logged through an event listener. But hooking into MessageSent means we do not have access to the job (and the payload).

The second event we can look at is the JobProcessed event. An example of what we tried is below:

Queue::after(function (JobProcessed $processed) {
    $payload = $processed->job->payload();
    $command = unserialize($payload['data']['command']);

    if (property_exists($command, 'mailable') &&
        method_exists($command->mailable, 'completed')
    ) {
        $command->mailable->completed();
    }

    if (method_exists($command, 'completed')) {
        $command->completed();
    }
});

This works and solves most of our requirements. It allows us to keep the log entries (or other actions) close to the actual job, and although I didn't include it in the workaround, we can inject the payload into the mailable.

Unfortunately, there is a problem with this workaround. We would need the payload in the failed method too. Without it, we don't know which user triggered it. The alternative is to drop the failed method and listen for JobFailed events, essentially using the same logic as completed jobs. We do not want to do this as it moves us away from Laravel's core.

TL;DR

1. We would like queued mailables to access the job's payload (InteractsWithQueue?).
2. We would like to introduce a completed method on all jobs, including queued mailables.