feat(logger): use async local storage for logger

[svozza]

Summary

This PR adds support for using an async context (specifically from the InvokeStore package) in the Logger utility. This allows users to emit log statements that are isolated specifically to the current lambda invocation, isolated from any other executions.

Changes

• Added a specific storage class for log attributes: LogAttributesStore
• The Logger class only accesses the data in this store through this interface and never touches the stored objects directly.
• Updated all methods that stored log attributes and log keys to use the new storage class.
• The storage class checks whether it is running in the InvokeStore context: if they are then the log keys are stored in the current async context, otherwise we fallback to a plain instance wide object as per the current implementation.
• Moved the sequence testing function to the common testing package.
• Added specific concurrency tests to ensure isolation is working as intended for the LogAttributesStore and theLogger class as a whole.

Issue number: closes #4667

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

[sdangol]

Just a small question. Rest looks good from my side.

[sdangol]

Do we need to check #checkReservedKeyAndWarn here as it was before?

[svozza]

Ah good catch!

[svozza]

So looking into this a bit more, I was surprised that we didn't have a failing test case in light of this removal.

Upon investigation, I have found that #appendKeys already does this check but the deprecated setPersistentLogAttributes does not. However, we do not have a unit test that uses setPersistentLogAttributes to set a reserved keyword. Upon adding a test case that does this I now had a failing unit test.

Initially I thought that rather than adding reserved key filtering logic to setPersistentLogAttributes that I would instead centralise it in #createAdditionalAttributes as this method is called whenever any log statement is emitted in the createAndPopulateLogItem method. This centralisation would allow us to remove the check from #appendKeys too.

However, when I implemented this, the tests that check for reserved keys started failing with stack overflow errors. This makes sense because the #checkReservedKeyAndWarn function itself has a log statement in it. If you try to use it to do a check in createAndPopulateLogItem you will trigger an infinite loop of log statements.

What I have done instead is add a new function called filterReservedAttributeKeys and used it in both #appendKeys and setPersistentLogAttributes (even though the function is deprecated, it is still part of the public API for now) so that reserved keys will not be added to the store. I have also removed the #createAdditionalAttributes method entirely and we just call this.#attributesStore.getAllAttributes() directly now.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud