fix(http-client-python): api_version validation decorator reads correct config attribute name#11392
fix(http-client-python): api_version validation decorator reads correct config attribute name#11392l0lawrence wants to merge 9 commits into
Conversation
…ct config attribute name The generated _validation.py @api_version_validation decorator hardcoded `client._config.api_version`, but the config attribute name is derived from the API-version parameter's client_name. Specs that name the versioning parameter something other than `apiVersion` (e.g. Azure Storage Blob's `@apiVersion @Header("x-ms-version") version: string`, which produces `self.version`) hit an AttributeError that the decorator silently swallowed, disabling all API-version validation for those clients. Thread the real attribute name into the decorator via a `client_api_version_name` kwarg, emitted only when it differs from the default `api_version`. Also fix a latent NameError in the decorator's `unsupported` error-message branch that referenced an out-of-scope `version` variable. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 9e983f91-eed5-4191-b531-0eca9e696313
commit: |
|
All changed packages have been documented.
Show changes
|
|
You can try these changes here
|
Python emitter diffBaseline Diff summary: 4 file(s), +4 / -4 Rendered diff: inline on the run summary, or the emitter-diff-html artifact. Informational check (eng/emitter-diff); does not block the PR. |
…ion attribute fix Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 9e983f91-eed5-4191-b531-0eca9e696313
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 9e983f91-eed5-4191-b531-0eca9e696313
…he pylint suppression Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 9e983f91-eed5-4191-b531-0eca9e696313
…tattr Thread a client_api_version_getter (lambda config: config.<name>) into the decorator so the generated code reads self._config.<name> directly rather than via a getattr string lookup. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 9e983f91-eed5-4191-b531-0eca9e696313
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 9e983f91-eed5-4191-b531-0eca9e696313
Render config.<name> directly instead of threading a decorator kwarg; resolve the api-version attribute name once at package level from ConfigParameter.client_name. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 9e983f91-eed5-4191-b531-0eca9e696313
Read client._config.<name> directly; the baked-in short attribute name keeps the line under black's limit so the protected-access suppression stays attached. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 9e983f91-eed5-4191-b531-0eca9e696313
| names = { | ||
| parameter.client_name | ||
| for client in self.code_model.clients | ||
| for parameter in client.config.parameters.parameters |
There was a problem hiding this comment.
is there a cleaner way to get the config api_version name?
Root cause
The generated
_validation.py@api_version_validationdecorator (fromvalidation.py.jinja2) hardcoded:But the config attribute name is generated from the API-version parameter's
client_name(config.py.jinja2:self.{{ parameter.client_name }} = {{ parameter.client_name }}). Most specs name the paramapiVersion→self.api_version, so it works.Some specs name the versioning parameter
versioninstead — e.g. Azure Storage Blob, declared as@apiVersion @header("x-ms-version") version: string. Those clients getself.versionand notself.api_version, soclient._config.api_versionraisedAttributeError, which the decorator catches and silently no-ops. Result: all api-version validation was silently skipped for those clients.Caveat****: single shared decorator per package
_validation.pycontains a single shared@api_version_validationdecorator for the whole package, so only one api-version attribute name can be baked in._api_version_config_attr_name()therefore bakes the name only when all clients in the package agree on it; if a package ever had multiple clients using different api-version attribute names, the helper falls back to the conventionalapi_version. In practice a package's clients share one api-version name, which matches what_configuration.pygenerates.