Feature request: improve regex in stack trace parsing

[dreamorosi]

Use case

When formatting an error using the Logger utility I want to get the location of the error in my logs. To do so, the Logger utility parses the stack trace of an error and extracts the relevant info.

For example, the following stack trace:

'Error: Things keep happening!
   at /home/foo/bar/file-that-threw-the-error.ts:22:5
   at SomeOther.function (/home/foo/bar/some-file.ts:154:19)'

yields this location: /home/foo/bar/file-that-threw-the-error.ts:22:5.

At the moment we are using a regex expression (/\((.*):(\d+):(\d+)\)\\?$/) that has a couple of potential issues that could lead to unexpected behavior:

• Greedy Quantifier: The .* part of the regex uses a greedy quantifier. This means it will match as many characters as possible, which could lead to unexpected results if there are multiple colons in the string. For example, in the string "(foo:bar:1:2)", the .* part will match "foo:bar", not just "foo".
• Escaping Backslash: The \\? part of the regex matches an optional backslash at the end of the string. However, if since we're trying to match a single backslash, we only need to escape it once, not twice.

Solution/User Experience

The API/DX for the logger should remain the same and the change should be backwards compatible.

We should however improve the expression and change it to /\((.*?):(\d+):(\d+)\)\$?$/, this would:

• Remove the greedy quantifier: .* -> .*?
• Correct the escaping of the backslash: \\?$ -> \?$

Additionally, we should review the unit tests of the method associated with this expression and make sure they're exhaustive enough.

Alternative solutions

No response

Acknowledgment

• This feature request meets Powertools for AWS Lambda (TypeScript) Tenets
• Should this be considered in other Powertools for AWS Lambda languages? i.e. Python, Java, and .NET

Future readers

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

[karthikeyanjp]

I would like to contribute. Will submit a PR with the regex and unit tests.

[dreamorosi]

Hi @karthikeyanjp, thank you for reaching out.

I'll assign the issue to you and help merge the PR once ready.

[karthikeyanjp]

Referring to format of error locations as mentioned in https://nodejs.org/api/errors.html#errorstack & https://v8.dev/docs/stack-trace-api , we can support the following pattern:

1. plain-filename.js:line:column or /absolute/path/to/file.js:line:column or <transport-protocol>:///url/to/module/file.mjs:line:column wrapped in ().
2. location with multiple colon. Example at Script.runInThisContext (node:vm:130:12)
3. location from an eval statement.
   Example:

Error: unknown:
at eval (eval at <anonymous> (file:///home/foo/bar/some-file.ts:1:35), <anonymous>:1:7)
at <anonymous> (/home/foo/bar/file-that-threw-the-error.ts:52:3)

For pattern (3), the current & above proposed regex will extact eval at <anonymous> (file:///home/foo/bar/some-file.ts:1:35), <anonymous>:1) instead of /home/foo/bar/file-that-threw-the-error.ts:52: as there are two nested locations embedded within ().

I am proposing the regex /\(([^)]*?):(\d+):(\d+)\)\\?$/ . I tested and it works for all the cases.

Submitted PR #2194 .

@dreamorosi please let me know your thoughts on the new regex.

[github-actions]

⚠️ COMMENT VISIBILITY WARNING ⚠️

This issue is now closed. Please be mindful that future comments are hard for our team to see.

If you need more assistance, please either tag a team member or open a new issue that references this one.

If you wish to keep having a conversation with other community members under this issue feel free to do so.

[github-actions]

This is now released under v2.0.3 version!