framework: [5.1] Errors in views cause problems when running in queue daemon worker

I’ve run into the same problem as described in #9881, so please read that as this follows on, but with more findings, reproduction steps and discussion of a fixe.

As identified in a comment, if an error occurs when rendering a view while in a queue daemon worker, subsequent renderings use a previous rendering result. Seeing as the queue workers are most commonly used for mail and it’s easiest to reproduce like that, we will.

I have tested using the beanstalkd driver, but I presume any other than sync will work.

To reproduce: 1, Create an email view using blade @section and @yield, with a method for making it error on demand e.g. trying to echo an undefined variable based on data passed. 2. Send mail to queue using some data that will identify the content as being the 1st email, not triggering error in view. 3. Send mail to queue using some data that will identify the content as being the 2nd email, and triggering error in view. 4. Send mail to queue using some data that will identify the content as being the 3rd email, not triggering error in view. 5. Send mail to queue using some data that will identify the content as being the 4th email, not triggering error in view. 6. Run php artisan queue:work --daemon --tries=1

Expected result: 1st, 3rd and 4th emails received, content correct and different in all three.

Actual result: 1st email correct, 3rd email correct, 4th email has same content as 3rd email.

I’ve gone beyond what was figured in #9881 and chased this error through the framework and ascertained that the issue is due to the error in the rendering of the view in the 2nd email causing a problem with the section array/section stack in Illuminate\View\Factory. It seems that an error in a view in a previous job effectively get “left over” and causes problems with view rendering in future jobs.

A user-implementable workaround, which also proves the cause, is to add:

Queue::looping(function () {
    View::flushSections();
});

to e.g. the AppServiceProvider boot method. With this in place, the sections are forcibly flushed after every job, and the steps above can be re-run with the expected results achieved.

Exactly how best to approach fixing this in the framework, I am not sure, hence no pull request, but hopefully there is enough information here to be able to replicate this and work to getting it fixed, as this can potentially lead to inadvertently to sending emails with the sensitive information to the wrong recipients.