Feature request: POWERTOOLS_DEV=1 should pretty print stack traces

[everett1992]

Use case

import { Logger } from '@aws-lambda-powertools/logger'
const err = new Error('message')
console.log(err)
new Logger().error("err", err)

Compare native node formatting, with clear new line and indentation, to powertools

POWERTOOLS_DEV=1 node test.mjs
Error: message
    at file://test.mjs:2:13
    at ModuleJob.run (node:internal/modules/esm/module_job:193:25)
    at async Promise.all (index 0)
    at async ESMLoader.import (node:internal/modules/esm/loader:530:24)
    at async loadESM (node:internal/process/esm_loader:91:5)
    at async handleMainPromise (node:internal/modules/run_main:65:12)

{
    "level": "ERROR",
    "message": "err",
    "service": "service_undefined",
    "timestamp": "2023-03-09T19:29:41.087Z",
    "error": {
        "name": "Error",
        "location": "node:internal/modules/esm/module_job:193",
        "message": "message",
        "stack": "Error: message\n    at file://test.mjs:2:13\n    at ModuleJob.run (node:internal/modules/esm/module_job:193:25)\n    at async Promise.all (index 0)\n    at async ESMLoader.import (node:internal/modules/esm/loader:530:24)\n    at async loadESM (node:internal/process/esm_loader:91:5)\n    at async handleMainPromise (node:internal/modules/run_main:65:12)"
    }
}

Solution/User Experience

Powertools should print the stack trace similarly to native node.

Alternative solutions

I understand that may not be possible with JSON output. As an alternative powertools could provide a non-json, terminal-focused, formatter for development.

Im not sure if that meets the tenents

> AWS Lambda only. We optimise for AWS Lambda function environments and supported runtimes only. Utilities might work with web frameworks and non-Lambda environments, though they are not officially supported.

Acknowledgment

• [X] This feature request meets Lambda Powertools Tenets
• [ ] Should this be considered in other Lambda Powertools languages? i.e. Python, Java, and .NET

Future readers

Please react with 👍 and your use case to help us understand customer demand.

[dreamorosi]

Hi @everett1992, thank you for taking the time to open this issue.

As a developer I see the value of having a clearly readable stack trace, and I agree that the one currently being output doesn't fit this description.

With that said, I'm not sure whether it's possible to apply multi-line formatting to JSON values and as you already touched, removing the JSON structure would go against the main value proposition of the utility and tenets.

I need to actually test this and dive deeper into the current implementation, but I think we could evaluate the option of breaking the lines of the stack traces into an array of strings, which once pretty-printed would look like this:

{
    "level": "ERROR",
    "message": "err",
    "service": "service_undefined",
    "timestamp": "2023-03-09T19:29:41.087Z",
    "error": {
        "name": "Error",
        "location": "node:internal/modules/esm/module_job:193",
        "message": "message",
        "stack": [
            "Error: message",
            "at file://test.mjs:2:13",
            "at ModuleJob.run (node:internal/modules/esm/module_job:193:25)",
            "at async Promise.all (index 0)",
            "at async ESMLoader.import (node:internal/modules/esm/loader:530:24)",
            "at async loadESM (node:internal/process/esm_loader:91:5)",
            "at async handleMainPromise (node:internal/modules/run_main:65:12)"
        ]
    }
}

This type of behavior would be enabled only when POWERTOOLS_DEV is set to true | 1 like your proposal.

I realize that this is not exactly what you proposed, but I think it could be a reasonable middle ground that can provide a good readability while maintaining the ethos of the utility.

What do you/people think?

[everett1992]

Totally acceptable solution to me, tho it does change the schema of the json record, and would change how logs are stored in cloudwatch if POWERTOOLS_DEV=1 was used in lambda.

What about the option to log with a terminal friendly format in development?

[github-actions[bot]]

This issue has not received a response in 2 weeks. If you still think there is a problem, please leave a comment to avoid the issue from automatically closing.

[dreamorosi]

Hi Caleb, I see your point and the and I'm still on the fence about this.

I would like to gather some additional feedback from the community about the feature to understand how many people use the logger library locally.

Let's keep this open and revisit this sometime soon.

[quintinchris]

definitely +1 this feature. i work with a relatively large team of developers that run and test api gateways and lambdas locally (now utilizing the powertools logger), and it would be a huge benefit to have the logs be pretty printed when running locally.

as a suggestion, maybe this should be done automatically if running in a local environment? not sure how many consumers use SAM, but you can check if you're running on SAM local via the AWS_SAM_LOCAL env variable. with this approach there would be no need to change how logs are stored in cloudwatch, as you could be confident this would only occur locally

[dreamorosi]

it would be a huge benefit to have the logs be pretty printed when running locally.

Hi @quintinchris, just to clarify: you can already pretty print logs by setting the POWERTOOLS_DEV environment variable, this issue proposes extending the behavior to stack traces, that are currently logged as they are emitted.

[StianHanssen]

Just adding to this, that also for those using the serverless framework, it is very common to test the lambda locally first via serverless invoke local.

Myself and a colleague had a very similar conversation on the python side of the library. There we came to a nice resolution where there is customizability to have a different local logger, that behaves like a typical local logger (non-json). The thread can be found here: https://github.com/aws-powertools/powertools-lambda-python/issues/409