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_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
- Or change
_ComponentConfig Protocol to use ClassVar — but this conflicts with the decorator's runtime instance-attribute assignment
- 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
Context
The
@_additional_propertiesdecorator atopentelemetry-sdk/src/opentelemetry/sdk/_configuration/_common.pyadds anadditional_propertiesfield to generated config dataclasses. The customdatamodel-codegentemplate atopentelemetry-sdk/codegen/dataclass.jinja2declares it asClassVar[dict[str, Any]]even though the decorator sets it as an instance attribute at runtime.The shared
_resolve_componentutility (added in #5215) uses a_ComponentConfigProtocol declaringadditional_propertiesas an instance attribute. Under pyright'sstandardmode (the project default), this mismatch is tolerated. Understrictmode, pyright reports:Why this matters
Suggested investigation
additional_propertiesas a regular instance attribute with a default:additional_properties: dict[str, dict[str, Any] | None] = field(default_factory=dict)fieldimport in the generatedmodels.pyand may need template adjustments_ComponentConfigProtocol to useClassVar— but this conflicts with the decorator's runtime instance-attribute assignment# type: ignoreannotations (least preferred — AGENTS.md discourages them)Acceptance criteria
_configurationtypes pass pyright instrictmodemodels.pyaccurately reflects runtime behaviourRelated
_ComponentConfigProtocol with broader typing and noted this fragility@_additional_propertiesdecorator and codegen template