resource.update doesn't pass by_alias, mangling keyword-named fields

[negz]

What happened?

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.

This 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:

data = source.model_dump(exclude_unset=True, warnings=False)
# -> {"bool_": True}, but the resource's field is "bool"

The 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.

This 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.

How can we reproduce it?

Generate a model for a CRD with a field named bool (or int/from/continue/schema), then compose it:

# Generated model: bool_ aliased to "bool".
attrs = Attributes(**{"bool": True})

attrs.model_dump(exclude_unset=True)
# {'bool_': True}   <- wrong key in the composed resource

attrs.model_dump(exclude_unset=True, by_alias=True)
# {'bool': True}    <- correct wire name

resource.update uses the first form, so the desired resource ends up with bool_.

How could the SDK help solve it?

Pass by_alias=True alongside exclude_unset=True in both resource.update and resource.update_status.

It'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.

What environment did it happen in?

• crossplane/function-sdk-python: main (and the exclude_unset branch from Serialize models with exclude_unset, not exclude_defaults #208)
• Models generated by datamodel-code-generator via the Crossplane CLI, which emits keyword-collision field aliases (see crossplane project build generates broken Python schemas for OpenAPI fields named int/bool cli#63, Fix Python schema generation for fields named int or bool cli#64)