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

• refactor(config): add shared _resolve_component utility for plugin loading #5215 introduced the _ComponentConfig Protocol with broader typing and noted this fragility
• feat(config): add additionalProperties support to generated config models #5131 introduced the @_additional_properties decorator and codegen template