Automatically reset Monolog processors between background jobs

[mortenscheel]

Monolog provides a ResettableInterface that allows Processors and Handlers to reset their state, which can help avoid memory leaks in long running processes.

Telling Monolog to reset all resettable handlers and processors at the start of each background job is pretty simple:

\Event::listen(JobProcessing::class, function (JobProcessing $event) {
    $logger = app('log')->driver()->getLogger();
    if ($logger instanceof \Monolog\ResettableInterface) {
        $logger->reset();
    }
});

But maybe this is something Laravel should do automatically?

I haven't personally experienced memory leaks due to logging, but I like adding Monolog's UidProcessor which appends an identifier to all log messages that changes between each request. This makes it super easy to find all log messages related to a specific request, but since queue workers reuse the same Logger instance, the log uid remains the same for the lifetime of the worker.

[Skipper2107]

I have a similar problem, but ended up with a new queue worker

class ResetLoggerAwareWorker extends Worker
{
    public function __construct(
        private readonly LogManager $logger,
        QueueManager $manager,
        Dispatcher $events,
        ExceptionHandler $exceptions,
        callable $isDownForMaintenance,
        callable $resetScope = null
    ) {
        parent::__construct($manager, $events, $exceptions, $isDownForMaintenance, $resetScope);
    }

    protected function runJob($job, $connectionName, WorkerOptions $options)
    {
        try {
            return parent::runJob($job, $connectionName, $options);
        } finally {
            $logger = $this->logger->driver();
            if ($logger instanceof Logger) {
                $logger = $logger->getLogger();
            }
            if ($logger instanceof \Monolog\Logger) {
                $logger->close();
            }
            if ($logger instanceof ResettableInterface) {
                $logger->reset();
            }
        }
    }
}

the problem is with Worker::runJob bc all queue events are being fired inside Worker::process, but outside this method we call ExceptionHandler::report which will create a new log entry, with a new log uuid, and this uuid will be reused in the next queue iterration. Imagine you get an error, all your logs are written with uuid a, you reset this uuid, uuid becomes b, then exception handler writes this error with uuid=b, and the next queue will get the same b. Imagine the next queue is successful, but in kibana you see an error from a previous job.