-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Add more control on infinite loop detection #2021
Description
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?