-
Notifications
You must be signed in to change notification settings - Fork 298
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Constructor middleware broken by #589 #594
Comments
We're also encountering this issue when trying to set up state on the controller for the request via middleware in the constructor (i.e. loading something common to all methods of a constructor), the data is correctly set but when it invokes the actual controller method the data is no longer set. As far as I'm aware, that's how we're intended to set state since the introduction of middleware. I'm wary of reverting to a prior version of Octane, as issue that PR #589 fixed implied that there was a bug that could cause a rather serious issue:
I'm unsure if that was specific to how they were working with Octane or not though. |
Further to my previous comment, it looks like the middleware might being ran on the old controller instance or something peculiar like that. This is some rudimentary logging to show a similar flow (middleware in a base controller's constructor, then a method within a controller that extends it).
At the end (the ERROR line), is where it encounters the data not set (it seems to consistently fail after a page load, form submission, redirect, form submission, fail). The <?php
namespace App\Http\Controllers;
use Illuminate\Routing\Controller;
abstract class BaseController extends Controller
{
public function __construct()
{
info('BaseController: __construct');
$this->middleware(function ($request, $next) {
info('BaseController: middleware');
// Set data here
return $next($request);
});
}
} <?php
namespace App\Http\Controllers;
use Illuminate\Http\Request;
class RegisterController extends BaseController
{
public function create()
{
info('ControllerWithMethod: create');
// access data
return view('form');
}
public function store(Request $request)
{
info('ControllerWithMethod: store (validation fails on purpose, redirect to create)');
// validate data - fail & return to previous page
}
} |
@aaronhuisinga @rndb8418 Can you update to the latest version of Laravel Framework and Octane, and tell us if you are still experience any issues? |
@nunomaduro Yes on latest versions ( |
I've done a completely fresh install like:
<?php
use App\Http\Controllers\HomeController;
use Illuminate\Support\Facades\Route;
Route::get('/', HomeController::class);
<?php
namespace App\Http\Controllers;
class Controller extends \Illuminate\Routing\Controller
{
protected array $example;
public function __construct()
{
$this->middleware(function ($request, $next) {
$this->example = ['foo' => 'bar'];
return $next($request);
});
}
}
<?php
namespace App\Http\Controllers;
class HomeController extends Controller
{
public function __invoke()
{
var_dump($this->example);
}
}
|
We've sent in some fixes for this. These will be released on Tuesday. |
Fixed on the most recent version of Laravel. |
If anyone is trying to use Octane with a fresh install of Laravel 11, you need to modify your controllers. From The error was something like "Target [App\Http\Controllers\Controller] is not instantiable.". |
Description:
After #589 was merged, we've had an issue causing us to revert to v1.3.1. In several of our applications running Octane, we create a BaseController that allows us to reference the current user via
$this->user
in all of our Controllers that extend it. The code we use is the following:For some reason, #589 is causing
$this->user
to always be empty. The value is set in the constructor, but appears not to persist so that it can be referenced by methods in Controllers extending this base Controller.For example, the following will throw an exception saying that we cannot access the $user property until it has been initialized:
I'm not sure that this is an intended consequence of flushing the controller, but this is a nice little helper we've been using in Octane.& non-Octane Laravel applications for years, and we've never had an issue with it until now.
Is this the intended behavior now and something that we should approach differently? Is this a bug caused by flushing the Controller? It seems to me that this is something that should work correctly.
The text was updated successfully, but these errors were encountered: