Skip to content

BUG: Disabled debug logs stringify default values and can break registration #3903

Open

Description

@romanlutz

Describe the bug

Two DEBUG log statements in pyrit/common/apply_defaults.py:121,355 eagerly stringify arbitrary default values even when DEBUG is disabled. A value with a raising __str__ causes registration to raise after storing the value, and prevents a decorated constructor from being entered. Passing the same value explicitly works.

This is a focused runtime fix and regression request, not blanket adoption of Ruff G rules. #3721 is open but already has open implementation PR #3843 for RUF/F changes; that work does not cover these default-value logging sites.

Steps/Code to Reproduce

import importlib
import logging

defaults = importlib.import_module("pyrit.common.apply_defaults")

class Value:
    def __str__(self):
        raise RuntimeError("Cannot render this value")

class Recipient:
    @defaults.apply_defaults
    def __init__(self, *, value=None):
        self.value = value

original_level = defaults.logger.level
defaults.logger.setLevel(logging.INFO)
try:
    defaults.set_default_value(
        class_type=Recipient, parameter_name="value", value=Value()
    )
finally:
    defaults.reset_default_values()
    defaults.logger.setLevel(original_level)

Use an isolated process: the example resets global default-value registrations during cleanup.

Expected Results

Disabled DEBUG must not call __str__ on the default value. Use lazy logging arguments at the two proven sites. Retain value identity, explicit overrides, false/zero/empty controls, and ordinary DEBUG-enabled message text.

Add targeted tests for registration, constructor-default resolution, and decorated construction. Broad lint adoption is not required.

Actual Results

Registration raises RuntimeError after retaining the value. In the full public-API probe, a nonthrowing counted object receives cumulative __str__ calls of 1, 2, and 3 across registration, resolution, and construction, while DEBUG is disabled. A throwing object also prevents the decorated constructor from entering; explicit injection succeeds.

Only custom synthetic values were exercised; no built-in plugin failure or production-frequency claim. A throwing __str__ at actual DEBUG emission is outside this disabled-logging fix.

Screenshots

N/A.

Versions

Linux; Python 3.12.3; actual default APIs and standard-library logging at PyRIT revision 01ce6ca66a315770b36c7dca1f320668c0d92d7c. Standalone offline probes; existing pytest suites were not run. No provider, memory backend, or initialization workflow was exercised. Full package-version output was not collected.

Activity

  1. akhil9tiet commented on Nov 4, 2026

    @akhil9tiet

    I'd like to work on this — please assign it to me.

  2. added 2 commits that reference this issue on Nov 4, 2026
    50b9f66
    b78497a
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions