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

Aperta Adatta ai principianti
  • Qualcosa non va?
#8,778 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@saimcyber ci sta già lavorando.

Dal 12/11/2026.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
68/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
python
Ambito
backend

Direzione di ricerca

L’issue indica la gestione del livello dei Logger figli e refresh_sample_rate_calculation() come comportamento interessato, ma non fornisce alcun percorso di file o di test. Inizia seguendo la costruzione dei Logger e l’aggiornamento della frequenza di campionamento nel pacchetto Python, poi trova i test correlati ai logger. Il lavoro è completato quando un figlio senza un livello esplicito segue il livello configurato e campionato del genitore, mentre un figlio con un proprio livello lo mantiene; aggiungi test per i casi segnalati.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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
Lingua principale
Python
Stelle
3.3k
Fork
511
Merge medio
3g 8h
PR unite (30g)
103

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di aws-powertools/powertools-lambda-python

Tutte le issue di aws-powertools/powertools-lambda-python

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.