Maintenance: add tests for child logger attributes

[saragerion]

Description of the feature request

Problem statement

During a 1:1 feedback session it emerged that the current behavior of Logger.createChild might not be immediately clear to people approaching the library for the first time. Likewise, the current unit test cases, while reaching 100% coverage, might use some improvements to cover all cases.

The steps to complete this issue should be (in this order):

• Assess the current implementation of both feature and tests
• Compare the implementation with current documentation section
• Report findings / proposed improvements (under this issue). The report should cover: 1/ are current unit tests covering all cases? If not, which cases could be added? 2/ does current documentation articulate clearly the behavior of createChild? If not, what would you add?
• Implement any changes that might have emerged from point above

Summary of the feature

N/A

Code examples

Unit tests for the feature: link
Implementation for the feature: link

Benefits for you and the wider AWS community

Describe alternatives you've considered

Additional context

N/A

Related issues, RFCs

N/A

[shdq]

Hello there! As part of the work on the childLogger @dreamorosi asked to look at this issue and fill in the gaps.

• Assess the current implementation of both feature and tests
• Report findings / proposed improvements (under this issue). The report should cover: 1/ are current unit tests covering all cases? If not, which cases could be added? 2/ does current documentation articulate clearly the behavior of createChild? If not, what would you add?

During two rounds of improvements (PR #1178 and PR #1267) implementation was changed and weak spots of unit tests were uncovered and necessary adjustments were added. Especially the test in the last PR covers all child logger attributes assesses against non-default values which was an issue with previous tests.

• Compare the implementation with current documentation section

childLogger is slightly mentioned in docs under Using multiple Logger instances across your code. For people who came from powertools for python it can be confusing since there all state changes will be propagated bi-directionally between child and parent. Here in TypeScript after the creation, they live separate lives and don't influence each other. Only attributes passed to childLogger will be overwritten. I think it should be mentioned in the docs or even explicitly list all the attributes that can be overwritten.

I would also add an example with a child logger where it implicitly inherits some parent's attributes, like logFormatter from this issue #1264. I would also add general use cases for child loggers in lambda functions (need help with that).

[dreamorosi]

Hey Sergei, thank you for looking into this and for the assessment.

I agree that perhaps we can improve this section of the docs.

Only attributes passed to childLogger will be overwritten. I think it should be mentioned in the docs or even explicitly list all the attributes that can be overwritten.

In regards to this I would say that as a user you can overwrite any of the settings that can also be set via constructor, which are the default ones, any persistent attributes, and the log formatter.

I would also add an example with a child logger where it implicitly inherits some parent's attributes

Maybe we could update the example in this section to not only show that you can overwrite but also that other attributes are passed down to the child. Maybe we could set service name and/or persistent attribute - similar to this:

import { Logger } from '@aws-lambda-powertools/logger';

// This logger has a service name, some persistent attributes
// and log level set to INFO
const logger = new Logger({
    serviceName: 'serverlessAirline',
    logLevel: 'INFO',
    persistentLogAttributes: { 
        aws_account_id: '123456789012',
        aws_region: 'eu-west-1',
    },
});

// This other logger inherits all the parent's attributes 
// but the log level, which is now set to ERROR
const childLogger = logger.createChild({
    logLevel: 'ERROR'
});

We should also modify the CloudWatch log excerpt (other tab).

like logFormatter from this issue #1264

I would add a "tip" box (see here) in the section that talks about custom log formatter instead saying something like: "When you set a custom formatter it is propagated/passed down to any children logger" (worded more nicely maybe)

I would also add general use cases for child loggers in lambda functions (need help with that).

We have another issue tracking the creation of a "recommended / best practices" section in the docs to cover this type of topic. I would defer this last point to that issue/discussion (perhaps we could add a comment under that issue linking to here to not forget), but I would leave it out for now as it's not strictly related to how the logger works.

What do you think?

[shdq]

Thank you for the proposals, I like them! So I'm going to make a PR, and let's continue with the discussion there.

[github-actions]

⚠️ COMMENT VISIBILITY WARNING ⚠️

Comments on closed issues 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.