-
-
Notifications
You must be signed in to change notification settings - Fork 368
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cloudwatch logs formatted similar to native Runtime, v2 #590
Conversation
When a handler throws an exception, it will no longer show up in the logs as `Fatal error: Uncaught <exception class>: <message> in <file>:<line>`. This gives the feeling that the developer should catch it. Instead, developers should let exceptions bubble up. The new log message will only contain the message of the exception itself. Hopefully, that's clearer, less noisy.
See brefphp/logger#3: we are trying to copy the log format of other AWS runtimes. Having the request ID in the log line lets use easily filter logs to find all the logs of a single invocation.
@@ -78,7 +78,7 @@ private function closeReturnHandler(): void | |||
/** | |||
* Process the next event. | |||
* | |||
* @param Handler|callable $handler If it is a callable, it takes two parameters, an $event parameter (mixed) and a $context parameter (Context) and must return anything serializable to JSON. | |||
* @param Handler|RequestHandlerInterface|callable $handler If it is a callable, it takes two parameters, an $event parameter (mixed) and a $context parameter (Context) and must return anything serializable to JSON. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unrelated fix, sorry about the noise!
'errorType' => get_class($error), | ||
'stackTrace' => explode(PHP_EOL, $error->getTraceAsString()), | ||
'errorMessage' => $error->getMessage(), | ||
'stackTrace' => $stackTraceAsArray, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to be certain to have the same order as Node.
One last benefit that might be worth mentioning: CloudWatch search will make sense. |
Thanks for the feedback! Let's get this going then! |
This PR starts from #579 and adds tests + adds a few things.
The problem
To reuse what @deleugpn described in #579: current errors in PHP lambdas appear like this in logs (CloudWatch):
This is hard to read, and this is not consistent with official runtimes like NodeJS. NodeJS logs an exception like this:
This PR
With these changes, here is how logs will look like:
In short, the error is formatted in JSON. Looking good!
Other changes:
Fatal error:
(the log line containsInvoke Error
, so that's less noise)Uncaught exception:
: we don't want users to think "oh I need to catch exceptions" -> exceptions should not be caught, instead Lambda will handle themBonus: how the execution result looks in
serverless invoke
:How the logs look in
serverless logs
(yuck…):