fix(logger): prevent overwriting standard keys

[dreamorosi]

Summary

Changes

Please provide a summary of what's being changed

This PR fixes a bug that allowed customer payloads to override Powertools-managed keys in logs.

Logger has a set of keys that are added to every log entry, for example level, timestamp, service, and more. These keys are what make logs discoverable.

Due to a bug, in some cases when customers appended keys to the Logger instance or passed extra keys to a log method, some of the service keys would be overridden by the customer-provided keys.

For example:

const user = {
  name: "john",
  level: "assistant"
};

logger.debug("user info", user);

In this case the level key from the user object would override the level in the log entry.

This PR fixes this bug and makes it so that when a customer-provided key conflicts with a reserved key, Logger will drop the customer one and log a warning.

Please add the issue number below, if no issue is present the PR might get blocked and not be reviewed

Issue number: fixes #3217

---

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.

[dreamorosi]

Ran e2e tests and they're passing.

[leandrodamascena]

I'll review this today morning.

[leandrodamascena]

Hi @dreamorosi, I left a comment about protected keys.

Another thing is that even I consider this a bug because the customer may end up having some logs with level: 'BLABLA and this is not a valid log level + we should enforce good practices. But this is a breaking change both in terms of possible data loss and in the customers' CI with warnings popping up in their pipeline and possible breaking this. We must highlight this in the documentation/release notes and monitor if we have customers complaining.

My vote is to move forward with this PR, but monitor the feedback after releasing it.

[dreamorosi]

Another thing is that even I consider this a bug because the customer may end up having some logs with level: 'BLABLA and this is not a valid log level + we should enforce good practices. But this is a breaking change both in terms of possible data loss and in the customers' CI with warnings popping up in their pipeline and possible breaking this. We must highlight this in the documentation/release notes and monitor if we have customers complaining.

My vote is to move forward with this PR, but monitor the feedback after releasing it.

I added two callouts to the docs, one in the structured keys section:

and one in the section that talks about adding keys (the link goes to the previously mentioned one):

I also updated the API docs for the two methods so they include the same info:

see in IDE:

and in the API docs:

---

I also improved the types of the methods so that customers can get an error in their IDE if they try to set one of these keys.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[leandrodamascena]

Thank you for improving the PR based on feedback and helping customers identify potential issues before pushing code to production.

Approved.