René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"resource.update doesn't pass by_alias, mangling keyword-named fields","articleBody":"### What happened?\n\n`resource.update` and `resource.update_status` serialize Pydantic models with `model_dump(exclude_unset=True)` (`exclude_defaults=True` before #208), neither of which passes `by_alias=True`. So a model field that carries a Pydantic alias is serialized under its **Python attribute name** rather than its alias, and the alias is the resource's real wire/JSON name.\n\nThis bites fields whose KRM name is a Python keyword. `datamodel-code-generator` (which `crossplane xpkg generate` / the CLI uses to generate models) can't name a field `bool`, `int`, `from`, `continue`, or `schema`, so it emits a `bool_` attribute aliased to `bool`, `int_` aliased to `int`, and so on. When a function composes a resource that sets such a field, `resource.update` writes the Python name into the desired resource:\n\n```python\ndata = source.model_dump(exclude_unset=True, warnings=False)\n# -\u003e {\"bool_\": True}, but the resource's field is \"bool\"\n```\n\nThe composed resource then carries `bool_: true` instead of `bool: true`, which doesn't match the resource's schema. The API server rejects it (or silently drops the unknown field), and the field the function set never takes effect.\n\nThis surfaced with Kubernetes Dynamic Resource Allocation, whose device attribute value is a one-of over `string`, `version`, `bool`, and `int`. `bool` and `int` generate aliased fields, so any function composing a DRA `ResourceClaim` / device attribute through a generated model hits this.\n\n### How can we reproduce it?\n\nGenerate a model for a CRD with a field named `bool` (or `int`/`from`/`continue`/`schema`), then compose it:\n\n```python\n# Generated model: bool_ aliased to \"bool\".\nattrs = Attributes(**{\"bool\": True})\n\nattrs.model_dump(exclude_unset=True)\n# {'bool_': True}   \u003c- wrong key in the composed resource\n\nattrs.model_dump(exclude_unset=True, by_alias=True)\n# {'bool': True}    \u003c- correct wire name\n```\n\n`resource.update` uses the first form, so the desired resource ends up with `bool_`.\n\n### How could the SDK help solve it?\n\nPass `by_alias=True` alongside `exclude_unset=True` in both `resource.update` and `resource.update_status`.\n\nIt's a safe, general fix. `datamodel-code-generator` only aliases fields whose names collide with Python keywords; every ordinary field — including camelCase ones like `clusterName` — is generated with the wire name as the attribute name and no alias, so `by_alias=True` is a no-op for them and corrects only the keyword cases. It's also orthogonal to the `exclude_unset` change in #208: one decides which fields are emitted, the other how they're named.\n\n### What environment did it happen in?\n\n- crossplane/function-sdk-python: `main` (and the `exclude_unset` branch from #208)\n- Models generated by `datamodel-code-generator` via the Crossplane CLI, which emits keyword-collision field aliases (see crossplane/cli#63, crossplane/cli#64)\n","author":{"url":"https://github.com/negz","@type":"Person","name":"negz"},"datePublished":"2026-06-08T20:09:03.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/210/function-sdk-python/issues/210"}