open-telemetry / open-telemetry/opentelemetry-python
refactor(config): review additional_properties typing for stricter type checks
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
- Change the codegen template to declare
additional_propertiesas a regular instance attribute with a default:additional_properties: dict[str, dict[str, Any] | None] = field(default_factory=dict)- This requires
fieldimport in the generatedmodels.pyand may need template adjustments
- This requires
- Or change
_ComponentConfigProtocol to useClassVar— but this conflicts with the decorator's runtime instance-attribute assignment - Or document the deliberate mismatch and add
# type: ignoreannotations (least preferred — AGENTS.md discourages them)
Acceptance criteria
_configurationtypes pass pyright instrictmode- Generated
models.pyaccurately reflects runtime behaviour
Related
- #5215 introduced the
_ComponentConfigProtocol with broader typing and noted this fragility - #5131 introduced the
@_additional_propertiesdecorator and codegen template
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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