Bug: child Logger without a level ignores its parent's log level since 3.6.0

Aberta Para iniciantes
  • Algo errado?
#8,778 2 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

@saimcyber já está trabalhando nisso.

Desde 12/11/2026.

Avaliação

Dificuldade
2/5
Tempo estimado
1-3 horas
Facilidade para iniciantes
68/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
python
Domínio
backend

Direção de pesquisa

A issue identifica o tratamento do nível dos Logger filhos e refresh_sample_rate_calculation() como o comportamento afetado, mas não fornece nenhum caminho de arquivo ou teste. Comece rastreando a construção de Logger e a atualização da taxa de amostragem no pacote Python; em seguida, encontre os testes relacionados a logger. O trabalho está concluído quando um filho sem nível explícito segue o nível configurado e amostrado do pai, enquanto um filho com nível próprio mantém esse nível; adicione testes para os casos relatados.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

Expected Behaviour

A child Logger (Logger(child=True)) created without a level should follow its parent's log level: a level set in the parent's constructor, later setLevel() calls, and debug sampling. That's how it worked up to 3.5.0, and it's what the docs describe: "All state changes will be propagated bi-directionally between Child and Parent."

Current Behaviour

Since 3.6.0 (#5950), a child without a level always ends up at INFO (or at POWERTOOLS_LOG_LEVEL when that's set) and stops following its parent:

  • parent level="DEBUG", setLevel("DEBUG") or sampling_rate=1: the child's DEBUG logs are dropped
  • parent level="WARNING": the child still emits INFO
  • a child that decorates the handler with POWERTOOLS_LOGGER_SAMPLE_RATE set: every warm invocation resets it to INFO
  • child.log_level always reports 20

#5950 was meant to let a child use its own level when one is passed. It also changed children that don't pass one.

Code snippet
# shared.py
from aws_lambda_powertools import Logger

logger = Logger(child=True)  # service comes from POWERTOOLS_SERVICE_NAME=payment


def work():
    logger.debug("child debug")
    logger.info("child info")


# app.py
import shared

from aws_lambda_powertools import Logger

logger = Logger(level="DEBUG")  # same with logger.setLevel("DEBUG") or Logger(sampling_rate=1)

shared.work()
# 3.5.0:  prints "child debug" and "child info"
# 3.6.0+: prints only "child info"  <- the child's DEBUG log is lost
Possible Solution

Only call setLevel on a child when a level is passed, so it stays NOTSET and inherits like before. The same goes for the level refresh_sample_rate_calculation() restores for a child. log_level should then return the effective level, so a child reports the level it actually logs at. I have a fix with tests ready and can open a PR once this is triaged.

Steps to Reproduce
  1. Put the two files above in a folder and set POWERTOOLS_SERVICE_NAME=payment.
  2. pip install aws-lambda-powertools==3.38.0, then run python app.py: only "child info" is printed.
  3. pip install aws-lambda-powertools==3.5.0 and run it again: both lines are printed.
Did you run the reproduction yourself?

Yes, I ran it and saw the failure

Powertools for AWS Lambda (Python) version

3.38.0 (broken since 3.6.0)

AWS Lambda function runtime

3.12

Packaging format used

PyPi

Debugging logs
Child Logger without a level, same two-module app on each version:

parent                                        3.5.0        3.6.0 - 3.38.0
level="DEBUG" / setLevel("DEBUG") / sampling  DEBUG+INFO   INFO only
sampling decorator, 2 warm invocations        both         INFO only
level="WARNING"                               nothing      child INFO leaks
child.log_level (parent DEBUG)                0            20
Linguagem predominante
Python
Estrelas
3.3k
Forks
511
Merge médio
3d 8h
PRs com merge (30d)
103

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de aws-powertools/powertools-lambda-python

Todas as issues de aws-powertools/powertools-lambda-python

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.