You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sorry if this is not the right place for my issue. I'll try to be brief.
In this pull, exception tracking during unit testing is introduced. Looking at FoundationServiceProvider code you can see the exception tracking code checks the context of every logged event looking for an 'exception' key. The code assumes the content of that 'exception' key to be an exception (or at least something that can be turned into a string) and adds it to a LoggedExceptionCollection instance bound for the test.
This change brakes many of my unit tests, the reason being I tend to include exceptions in the context of log messages already transformed into arrays in an 'exception' key, so they end up nicely serialized in log files. The listener code that checks log events for exceptions in the FoundationServiceProvider just looks into the 'exception' key in the context and runs with its content, which is a bit too broad in my opinion. Am I the only one using 'exception' in log contexts already transforming its content into arrays? It seemed a somewhat reasonable compromise...
I understand I can work around this issue rewriting my code into exceptions that handle their own log representation and sending those exceptions in the logs, which is probably the long term better approach. But I don't think this behaviour is intended and the code that reports exceptions from log messages should not assume so much from the log context's content.
I'm reporting this because I think it is not intended. I'm a big fan of the project, by the way.
Steps To Reproduce:
Anywhere in your code reachable by an http request. For example in api.php:
Route::get('exception', function () {
Log::info("Hi there", ['exception' => ['this can not be converted to a string']]);
returnresponse()->json(['The deed is done!']);
});
An integration test:
class ExceptionTest extends TestCase
{
/** @test */publicfunctioncheck_response_status()
{
$response = $this->json('GET', '/api/exception');
$response->assertStatus(200); // Throws an "Array to string conversion" error
}
}
The text was updated successfully, but these errors were encountered:
It's a general convention that the exception key has an exception object so that when the exception gets sent (for example) to Sentry via the Sentry Monolog handler you get the entire stack trace etc.
Description:
Sorry if this is not the right place for my issue. I'll try to be brief.
In this pull, exception tracking during unit testing is introduced. Looking at FoundationServiceProvider code you can see the exception tracking code checks the context of every logged event looking for an 'exception' key. The code assumes the content of that 'exception' key to be an exception (or at least something that can be turned into a string) and adds it to a LoggedExceptionCollection instance bound for the test.
This change brakes many of my unit tests, the reason being I tend to include exceptions in the context of log messages already transformed into arrays in an 'exception' key, so they end up nicely serialized in log files. The listener code that checks log events for exceptions in the FoundationServiceProvider just looks into the 'exception' key in the context and runs with its content, which is a bit too broad in my opinion. Am I the only one using 'exception' in log contexts already transforming its content into arrays? It seemed a somewhat reasonable compromise...
I understand I can work around this issue rewriting my code into exceptions that handle their own log representation and sending those exceptions in the logs, which is probably the long term better approach. But I don't think this behaviour is intended and the code that reports exceptions from log messages should not assume so much from the log context's content.
I'm reporting this because I think it is not intended. I'm a big fan of the project, by the way.
Steps To Reproduce:
The text was updated successfully, but these errors were encountered: