The return value of Error::decodeException contains a key called backtrace. This is often very large and contains a considerable number of large complex entities and objects. There are instances in core (and contrib #2954120: Return values of Error::decodeException not compatible with some loggers.) where this information is passed directly to \Psr\Log\LoggerInterface::log as part of $context.
Context does sound quite vague, however I do believe it's probably incorrect to pass megabytes of data into it, when it's reasonable to expect logging implementations will try and store this info. When used in conjunction with monolog for example, log messages are never stored due to the size of the callstack ($context is normalized during logging). From the PSR:
Every method accepts an array as context data. This is meant to hold any extraneous information that does not fit well in a string. The array can contain anything. Implementors MUST ensure they treat context data with as much lenience as possible. A given value in the context MUST NOT throw an exception nor raise any php error, warning or notice.
The reason this isn't an issue for core is, the first thing we do is unset 'backtrace' in DbLog:
public function log($level, $message, array $context = []) {
// Remove any backtraces since they may contain an unserializable variable.
unset($context['backtrace']);
We should make an effort to squash all instances of 'backtrace' before they are passed to the logger interface. In the meantime, individual loggers can take steps to remove the key, however I believe the root cause of the issue should be addressed.
Agree and patch.
Comments
Comment #2
sam152 commentedComment #3
sam152 commentedComment #4
sam152 commentedComment #5
sam152 commentedComment #6
sam152 commentedComment #7
sam152 commentedComment #8
sam152 commentedComment #9
sam152 commentedComment #10
sam152 commentedComment #11
jibran#2949419: Pass the raw exception to logger implementations is related.
Comment #12
mfbI've been trying to go in the other direction - providing more context to logger implementations as they can log it (often times with a nice user interface) and use it to fingerprint issues (linking exceptions together as the same issue). e.g. we added the raw backtrace for PHP errors at #2857437: pass raw backtrace to loggers for errors, not just exceptions since previously it was only being passed for exceptions.
I haven't looked around for what logger implementations are out there, but the one I maintain https://www.drupal.org/project/raven would regenerate the stacktrace if you don't provide one. Since core exception handler has it, why not pass it to a custom logger implementation to use if it can?
Comment #18
mfbI think this issue could be closed - we're now passing the exception object to loggers as well in #2949419: Pass the raw exception to logger implementations
As the PSR standard states
it's basically up to loggers to figure out how to represent or ignore each element of context data.
Comment #23
mfbClosing due to lack of discussion, but feel free to re-open