Closed theoboldalex closed 6 months ago
Any feedback on this appreciated @mnapoli
I'm sorry, while reviewing this I'm realizing this object follows a structure defined by AWS Lambda: https://docs.aws.amazon.com/lambda/latest/dg/runtimes-api.html#runtimes-api-invokeerror
I apologize for not spotting that sooner 🤦
I'm thinking of 3 options:
errorLocation
(current state of the PR) if it doesn't break error reporting and that new field shows up in the CloudWatch logsFor reference, here's what PHP logs in case of an uncaught exception:
Note: I don't think it's a good reference though because it's an "Uncaught exception" line that is a fatal error. In our case it's not exactly that, exceptions are OK (to communicate errors to Lambda), so we don't necessarily want to copy that format.
I think the 1st option is the best, but that requires testing on Lambda to confirm the behavior works as expected.
Closing inactive PRs, feel free to reopen.
resolves #1619
So that we can see the context of an error in Cloudwatch logs, I have added an
errorLocation
key to theerrorFormatted
data structure. This means that the file and line number where the exception is thrown is logged.