Description
After upgrading a Laravel 6 application to Laravel 7 I noticed that a test which was making assertions against behaviour which is executed in the terminate()
method of a custom middleware was failing.
After further inspection, I found that even though the application behaviour had not changed, the terminate()
method was never being called in the test. The laravel module calls terminate()
on the HTTP Kernel class, but passes in the original request object to the terminate()
method.
In order for the terminate()
method to be called on the route middleware, the applicable middlewares are fetched from route instance returned from $request->route()
if any. However, the route does not appear to be resolved on the request instance that gets passed into the terminate method.
It would appear to me that in the normal execution of the Laravel HTTP Kernel, the instance of the request that is being passed into the terminate method is being resolved out of the service container rather than being mutated by reference such as this test module code might expect. If you dump the request instance returned by request()
after the call to handle()
on the kernel you can see that the route has been resolved and bound to the request instance.
I haven't yet managed to isolate the specific change which is causing my test, which previously passed the original "laravel5" module and Laravel 6, and now fails with both Laravel 7, and 8 using this new "laravel" module. It might be a change in the Laravel framework, or it might be related to changes in the Codeception module.
Swapping the $request
variable with the request()
global helper function (which resolves the request out of the service container under the hood) fixed the issue. I'm not sure that this is the way you would want to fix it in a patch, since you might not want to rely on the request()
global function or use implicit service location like that, but it did confirm that this appears to be the problem.
$this->app->make(Kernel::class)->terminate(request(), $response);
I'd be happy to look at submitting a PR with a fix, but since the tests are in a different repo, I'll have to take a look at that repo and get my head around how the tests workflow goes. I wanted to leave this issue here in case anybody else hits this, and / or has a better idea of the cause or a solution.