-
Notifications
You must be signed in to change notification settings - Fork 153
Docs: add notice about mutating attributes in custom log formatters #3588
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hi @VladimirGorobetsWildix, thank you for opening this issue. The change of order of the fields has nothing to do with what you're observing. The change you're referring to was made in the in the default log formatter (here) which you're completely bypassing by providing your own custom log formatter (see logic that decides which one is used here). The reason why you're seeing this behavior is that you're mutating directly the I would recommend changing the logic in your log formatter to something like this, which I confirmed works as intended: class MyCompanyLogFormatter extends LogFormatter {
private hideFields = ['authorization', 'password', 'secret', 'key', 'token'];
processObject(obj: Record<string, any>) {
for (const key in obj) {
if (typeof obj[key] === 'object') {
this.processObject(obj[key]);
} else if (typeof obj[key] === 'string' && obj[key].length) {
if (this.hideFields.includes(key)) {
obj[key] = '**** hidden ****'; // Maybe incorrect solution, but it worked in 2.13.1
}
}
}
return obj; // return mutated object
}
public formatAttributes(
attributes: UnformattedAttributes,
additionalLogAttributes: LogAttributes
): LogItem {
const { message, ...rest } = structuredClone(attributes);
const logItem = new LogItem({
attributes: {
message,
},
});
try {
const sanitizedRest = this.processObject(rest);
logItem.addAttributes(sanitizedRest);
} catch {
logItem.addAttributes(rest);
}
try {
const sanitizedAdditional = this.processObject(
structuredClone(additionalLogAttributes) // now it's a deep clone and can be mutated
);
logItem.addAttributes(sanitizedAdditional);
} catch {
logItem.addAttributes(additionalLogAttributes);
}
return logItem;
}
} I have tested the implementation above with the latest version and confirmed it logs as expected, and leaves the {"message":"Lambda invocation event","logLevel":"INFO","timestamp":"2025-02-11T16:48:48.190Z","xRayTraceId":"1-67ab7f6f-722297141fd59b5c6ce6ed2e","awsRegion":"eu-west-1","serviceName":"service_undefined","sampleRateValue":0,"lambdaContext":{"invokedFunctionArn":"arn:aws:lambda:eu-west-1:123456789012:function:loggerorder-aamorosi-loggerOrderFunction-cefusswu","coldStart":true,"awsRequestId":"51f675cb-a01a-4afb-beb2-12ae229dbb81","memoryLimitInMB":"1024","functionName":"loggerorder-aamorosi-loggerOrderFunction-cefusswu","functionVersion":"$LATEST"},"event":{"headers":{"authorization":"**** hidden ****","content-type":"application/json"}}}
{"message":"==> Event in handler (secure)","logLevel":"INFO","timestamp":"2025-02-11T16:48:48.195Z","xRayTraceId":"1-67ab7f6f-722297141fd59b5c6ce6ed2e","awsRegion":"eu-west-1","serviceName":"service_undefined","sampleRateValue":0,"lambdaContext":{"invokedFunctionArn":"arn:aws:lambda:eu-west-1:123456789012:function:loggerorder-aamorosi-loggerOrderFunction-cefusswu","coldStart":true,"awsRequestId":"51f675cb-a01a-4afb-beb2-12ae229dbb81","memoryLimitInMB":"1024","functionName":"loggerorder-aamorosi-loggerOrderFunction-cefusswu","functionVersion":"$LATEST"},"event":{"headers":{"authorization":"**** hidden ****","content-type":"application/json"}}}
2025-02-11T16:48:48.196Z 51f675cb-a01a-4afb-beb2-12ae229dbb81 INFO ==> Event in handler (raw) {"headers":{"authorization":"Bearer aaa.bbb.ccc","content-type":"application/json"}} In the latest release we made some slight changes to how the attributes are handled internally to reduce object mutation and improve resource usage. Since they were internal changes we didn't include them in the release notes. Likewise, I would not consider this a regression, since the contract between the I will however open a PR to improve the documentation & examples around custom log formatters to advise customers to make a clone of these attributes if they intend to mutate them, rather than just rearrange/omit some of them. |
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. |
This is now released under v2.15.0 version! |
Expected Behavior
No change original event fields.
Current Behavior
Original event fields changed in logFormatter after upgrade 2.13.1 -> 2.14.0
Code snippet
Steps to Reproduce
@aws-lambda-powertools/logger: 2.13.1
==> Event in handler (raw) {"headers":{"authorization":"Bearer aaa.bbb.ccc","content-type":"application/json"}}
@aws-lambda-powertools/logger: 2.14.0
4 Receive response
==> Event in handler (raw) {"headers":{"authorization":"**** hidden ****","content-type":"application/json"}}
Possible Solution
No response
Powertools for AWS Lambda (TypeScript) version
2.14.0
AWS Lambda function runtime
22.x
Packaging format used
npm
Execution logs
The text was updated successfully, but these errors were encountered: