mirror of
https://github.com/Seldaek/monolog.git
synced 2026-04-25 23:55:56 +03:00
[GH-ISSUE #1965] add "__set_state" to Handlers to allow laravel config cache #848
Labels
No labels
Bug
Documentation
Feature
Needs Work
Support
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/monolog#848
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Curicows on GitHub (Apr 22, 2025).
Original GitHub issue: https://github.com/Seldaek/monolog/issues/1965
I have a project that uses the Laravel framework. I'm using the TelegramBotHandler to handle logs.
While it works perfect in the local environment, when I try to cache the Laravel config an error is thrown:
Inspecting the generated file before the "LogicException" has been thrown resulted in this cache:
The error occurs because when Laravel cache the config that directly instantiates an object it is transformed to call the static magic method "__set_state" of the class used. But an error is thrown because the Handler classes doesn't have this magic method.
I'm able to create a pull request to resolve that and if more information is needed I can provide it, thanks for the attention.
@Seldaek commented on GitHub (Oct 23, 2025):
I'm not sure what we can do about this. If __set_state doesn't exist I'd think Laravel's serializer should not attempt to call it. If it is due to a specific value we can try to resolve it but I'm not sure what that would be..
@dmohns commented on GitHub (Nov 10, 2025):
Also encountering this issues. Two questions here
FilterHandlercan be change to also accept aclass-stringand add a new option, i.e.handler_parametersthat will be used to instantiate it?@Seldaek commented on GitHub (Nov 10, 2025):
I am not sure what you mean.. FilterHandler receives a handler instances like all other wrapping handlers. I don't see it as practical to change this to a class + parameters for all wrapping handlers.
@dmohns commented on GitHub (Nov 10, 2025):
It was just a thought 😉 But yeah, if it's breaking the entire design of this library probably not worth to think about some changes that solve an issue that's really on Laravel side.
Laravel seems to do serialisation simply with
var_exportBy adding
__set_stateto the underlying handler (StreamHandlerin my case) I can get it to work (well... at least no throw an error), but similar to above: It's probably not worth for this library to maintain__set_statejust so Laravel can usevar_exportfor serialisation.