fix(logger): fix logger attribute merging

[okoskine]

Description of your changes

• logger attribute (context & custom persisted attribute) merges obey the expected priority, i.e. newly added values overwrite older ones
• logger attribute merges no longer mutate the user-provided attribute objects
• cold start heuristic is now based on the request id

How to verify this change

Newly added unit tests in Logger.test.ts

Related issues, RFCs

PR status

Is this ready for review?: YES
Is it a breaking change?: NO

Checklist

• My changes meet the tenets criteria
• I have performed a self-review of my own code
• I have commented my code where necessary, particularly in areas that should be flagged with a TODO, or hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• The code coverage hasn't decreased
• I have added tests that prove my change is effective and works
• New and existing unit tests pass locally and in Github Actions
• Any dependent changes have been merged and published in downstream module
• The PR title follows the conventional commit semantics

Breaking change checklist

• I have documented the migration process
• I have added, implemented necessary warnings (if it can live side by side)

---

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

[dreamorosi]

Hi @okoskine thanks a lot for opening this PR, we really appreciate it.

Before moving forward, and for future reference, I would politely ask you if it'd be possible to limit PRs to one feature only. This PR addresses two areas:

• Improvements to the cold start heuristic
• Edits to the way attributes are merged in the logger

According to our CONTRIBUTING guidelines we would appreciate it if next time you could open an issue first, or contribute to an existing one before publishing a PR.

In this case, as part of the work being done on issue #484 we are already working to refactor the cold start logic and extract it in the @aws-lambda-powertools/commons package. With this in mind I'd recommend reverting these changes as that portion of code will be removed anyway in a PR that will be up soon.

In regards to the merge logic for the attribute instead, could you please elaborate a bit more on what problem the change is solving? To better be able to review and understand the PR I'd appreciate if you could provide examples of the original and proposed behaviours so that we can better contextualise the changes.

Thanks in advance for the info and again, thank you also for taking the time to open this PR.

[okoskine]

Hi, I edited the PR not to include the cold start changes. I initially included these in a single PR since the coldStart value was also affected by the merge problems described here. I think the introduced unit tests now more easily show the intention as there are fewer changes. However, here's a quick explanation:

The merge function from lodash mutates the first parameter, so a call of the form

activeValues = merge(newValues, activeValues)

actually mutates the newValues object by adding the old activeValues contents and then binds that object also to the name activeValues.

The apparent intention of these usages is captured with the form

merge(activeValues, newValues)

which only mutates the activeValues object and overrides the old values with the new ones instead of the other way round.

The actual problem I encountered was that awsRequestId was not updated to the correct value on later invocations but stayed constant (the request id of the first (cold start) invocation). The same problem existed for appendKeys / addPersistentLogAttributes.

[dreamorosi]

@okoskine thanks a lot for the explanation and for accepting to exclude the cold start changes.

I'll review the changes & unit tests tomorrow morning and provide a review for the PR.

[dreamorosi]

Just reviewed the changes and they make sense to me, nice catch in spotting that the objects were mutated & at the same time multiple executions were not updating correctly.

Gonna ask a second review by @saragerion and when all comments are addressed I'll be happy to approve & merge.

[saragerion]

Looks great! Thanks for the PR and contribution 🎉
I added a nice-to-have nitpick comment, but in my opinion it's already ready to be merged.