powertools-lambda-typescript icon indicating copy to clipboard operation
powertools-lambda-typescript copied to clipboard

Feature request: improve regex in stack trace parsing

Open dreamorosi opened this issue 1 year ago • 0 comments

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

Future readers

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

dreamorosi avatar Feb 21 '24 16:02 dreamorosi