Alexander Stecher

Something else that would make this even more safe is removing all access to the initial app state in Octane's event listeners. The flushing of scoped instances and so on...

I agree, this should probably be refined more for a minor or major. Fixing the leak might not be possible though without adding an `$app` setter in the `ViewServiceProvider` class...

I've reset this PR to only specifically fix the #887 memory leak. The PR is waiting for [another PR in laravel/framework](https://github.com/laravel/framework/pull/51443). It won't break older versions since it checks if...

I think the main issue here and with possible other memory leaks is that Octane changes the reference to the application container on each request and then attempts to update...

Since I'm sick at home today anyways, I created an [initial draft](https://github.com/laravel/octane/pull/888). It would be nice if someone could look over it.

I can confirm that this leak is fixed in the newest Laravel Version 11.8.0. Closing this for now

This issue might also be caused by a stale container reference like #887. I'll try to verify on my experimental branch when I have time.

I was wrong, the `RouteUrlGenerator` actually just keeps its defaults across requests. If that's not intended, then Octane should probably do something like this in an event listener after each...

More specifically, it would be necessary to bind the state of the `RouteUrlGenerator` to the `$app` instance, since when setting a new `$request` in the `UrlGenerator`, we would want to...

I don't think this is a FrankenPHP issue. The problem here comes from copying the project folder into the app `COPY . /app` and at the same time mounting the...