Any idea of what might be the problem?
#Argument 1 passed to IlluminateCookieMiddlewareEncryptCookiesencrypt() must be an instance of S
errant fiber
exotic jolt
Luckily, I know exactly what the problem is:
Argument 1 passed to Illuminate\Cookie\Middleware\EncryptCookies::encrypt() must be an instance of Symfony\Component\HttpFoundation\Response
See the source: https://github.com/laravel/framework/blob/9.x/src/Illuminate/Cookie/Middleware/EncryptCookies.php#L170
errant fiber
I do not get what exactly you are trying to point to me.
exotic jolt
You asked what the problem was, so I told you
Try and look at the ignition stack trace for a clearer picture instead of dunking a one-line stack trace here asking what the problem is, when the first sentence specifically says why it broke
errant fiber
I do understand that the encrypt function do not get the expected argument, but i do not know what can be the potential problem to this.
exotic jolt
Look at the stacktrace in ignition, you know, the big fancy screen you get locally while developing.
Every piece of code you write isn't just ran as is, registering a route etc. will go through Illuminate components (Laravel) in a chain of responsibility until it's finally executed. So the big first error isn't always gonna be your error.
Hello: I am the error
↪️ Some other error that caused the error above
↪️ More errors
↪️ More errors
↪️ More errors
↪️ More errors
↪️ Your error
Discord formatting ruining me
And if reading a stacktrace isn't helpful, you start debugging in other ways, such as figuring out what triggers the error and when, replicate it, once you can replicate it you can narrow down the source of the problem.
Or a classic approach, undo what you just changed that broke things - then you know what exactly you added
errant fiber
The thing is, i get the error in production, and it is not reported in laravel.log.
In development everything looks fine and i could not recreate the error that im getting in production.
The way how i was able to get to this stacktrace is by returning the Throwable object in Handler.php.
exotic jolt
If you don't get anything logged, then that is broken too. This giant OL stacktrace is annoyingly impossible to read, I can skim out some TrustedProxies stuff, so that could easily be the case, but maybe not? You need to find a way to replicate the error, or figure out the steps you perform that will cause it to break while looking at the code being ran until you can determine where in the point of time things might differ from local -> prod.