[GH-ISSUE #2021] Add more control on infinite loop detection #862

New issue

Open

opened 2026-03-04 03:01:42 +03:00 by kerem · 0 comments

kerem commented

2026-03-04 03:01:42 +03:00

Owner

Originally created by @zamaldev on GitHub (Mar 2, 2026).
Original GitHub issue: https://github.com/Seldaek/monolog/issues/2021

In my flow, I am using http requests pool to get information from third party. But when I trigger an error from response handler, sometimes I got an infinite loop detection error. As I understood, it is caused by nature of response handlers (pretty async IMO because even dd() returns few results instead of one).
And there is no easy workaround how to manage it. For now everything that we have is just option to disable it (which I don't want to do because there may be real infinite loop). I have tried to extends Logger, but there are bunch on private properties and constants, so I have to literally copy whole class for this. Which I don't want so much to do.
My proposition to add a bit more control on it. For example: manage the trigger depth of infinite loop. I would say to have an option to change 3 messages to 5 or 6 (should work for me) or even add some callback handler (like we have with exceptions).
Maybe something like that:

        if ($logDepth === $this->infiniteLoopTriggerDepth) { // Currently - 3
            if (null === $this->infiniteLoopHandler) {
                $this->warning('A possible infinite logging loop was detected and aborted. It appears some of your handler code is triggering logging, see the previous log record for a hint as to what may be the cause.'); // Currently - just this message

                return false;
            }

            return ($this->infiniteLoopHandler)($level, $message, $context, $datetime);
        } elseif ($logDepth >= ($this->infiniteLoopTriggerDepth + 2)) { // Currently - 5; log depth 4 is let through, so we can log the warning above
            return false;
        }

So in my case, I will have options to increase the depth (to allow more messages appear) or at least include the original message into warning (so I can have more information while debug).

Any thoughts?

Originally created by @zamaldev on GitHub (Mar 2, 2026). Original GitHub issue: https://github.com/Seldaek/monolog/issues/2021 In my flow, I am using http requests pool to get information from third party. But when I trigger an error from response handler, sometimes I got an infinite loop detection error. As I understood, it is caused by nature of response handlers (pretty async IMO because even `dd()` returns few results instead of one). And there is no easy workaround how to manage it. For now everything that we have is just option to disable it (which I don't want to do because there may be real infinite loop). I have tried to extends Logger, but there are bunch on private properties and constants, so I have to literally copy whole class for this. Which I don't want so much to do. My proposition to add a bit more control on it. For example: manage the trigger depth of infinite loop. I would say to have an option to change 3 messages to 5 or 6 (should work for me) or even add some callback handler (like we have with exceptions). Maybe something like that: ```php if ($logDepth === $this->infiniteLoopTriggerDepth) { // Currently - 3 if (null === $this->infiniteLoopHandler) { $this->warning('A possible infinite logging loop was detected and aborted. It appears some of your handler code is triggering logging, see the previous log record for a hint as to what may be the cause.'); // Currently - just this message return false; } return ($this->infiniteLoopHandler)($level, $message, $context, $datetime); } elseif ($logDepth >= ($this->infiniteLoopTriggerDepth + 2)) { // Currently - 5; log depth 4 is let through, so we can log the warning above return false; } ``` So in my case, I will have options to increase the depth (to allow more messages appear) or at least include the original message into warning (so I can have more information while debug). Any thoughts?