open-telemetry / open-telemetry/opentelemetry-python

refactor(config): review additional_properties typing for stricter type checks

Open
#5,268 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
2.6k
Forks
1k
Avg merge
4d 15h
Merged PRs (30d)
19

Description

Context

The @_additional_properties decorator at opentelemetry-sdk/src/opentelemetry/sdk/_configuration/_common.py adds an additional_properties field to generated config dataclasses. The custom datamodel-codegen template at opentelemetry-sdk/codegen/dataclass.jinja2 declares it as ClassVar[dict[str, Any]] even though the decorator sets it as an instance attribute at runtime.

The shared _resolve_component utility (added in #5215) uses a _ComponentConfig Protocol declaring additional_properties as an instance attribute. Under pyright's standard mode (the project default), this mismatch is tolerated. Under strict mode, pyright reports:

"additional_properties" is not defined as a ClassVar in protocol (reportArgumentType)

Why this matters

  • Anyone enabling stricter type checks on the SDK would hit this immediately
  • It's a structural inconsistency: the type annotation says class variable, the runtime behaviour is instance attribute
  • It blocks future moves toward stricter type checking

Suggested investigation

  1. Change the codegen template to declare additional_properties as a regular instance attribute with a default: additional_properties: dict[str, dict[str, Any] | None] = field(default_factory=dict)
    • This requires field import in the generated models.py and may need template adjustments
  2. Or change _ComponentConfig Protocol to use ClassVar — but this conflicts with the decorator's runtime instance-attribute assignment
  3. Or document the deliberate mismatch and add # type: ignore annotations (least preferred — AGENTS.md discourages them)

Acceptance criteria

  • _configuration types pass pyright in strict mode
  • Generated models.py accurately reflects runtime behaviour

Related

  • #5215 introduced the _ComponentConfig Protocol with broader typing and noted this fragility
  • #5131 introduced the @_additional_properties decorator and codegen template

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with opentelemetry-sdk/codegen/dataclass.jinja2, opentelemetry-sdk/src/opentelemetry/sdk/_configuration/_common.py, and the generated models.py files; inspect how the decorator and _ComponentConfig Protocol describe additional_properties. Run pyright in strict mode on _configuration and verify that the generated types match runtime behavior and the strict check passes.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
build-system, tooling
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.