What problem are you facing?
request.get_required_resource (and get_required_resources) returns None/[] in two semantically different cases: the requirement hasn't been resolved by Crossplane yet, and the requirement resolved but matched nothing. The only way to tell them apart is to also check name in req.required_resources, which the get_required_resources docstring documents as a caveat the caller must handle by hand.
This distinction matters whenever a function gates on an external resource. "Not resolved yet" is transient — wait and let Crossplane re-call. "Resolved, matched nothing" is a real state — the resource was deleted, or its reference is a typo — and usually wants a different response (e.g. a warning, or holding steady rather than waiting). Functions end up reimplementing the same in-then-get dance. We hit it twice in one project: once gating a hydration Job on an auth Secret, and once gating replica placement on a referenced cache being resolvable.
How could this Function help solve your problem?
A small helper that classifies a required resource into the three states, so callers don't each re-derive it from the in check. Roughly:
class Resolution(enum.Enum):
UNRESOLVED = "unresolved" # Crossplane hasn't fetched it yet (key absent)
ABSENT = "absent" # resolved, but nothing matched
PRESENT = "present" # resolved and found
def resolve_required(req, name) -> tuple[Resolution, dict | None]: ...
A list variant (and possibly the same for require_schema/get_required_schema, which has the analogous distinction) would round it out. Naming/placement and whether this is an enum vs. a small result type are open — happy to send a PR once there's a preferred shape.
What problem are you facing?
request.get_required_resource(andget_required_resources) returnsNone/[]in two semantically different cases: the requirement hasn't been resolved by Crossplane yet, and the requirement resolved but matched nothing. The only way to tell them apart is to also checkname in req.required_resources, which theget_required_resourcesdocstring documents as a caveat the caller must handle by hand.This distinction matters whenever a function gates on an external resource. "Not resolved yet" is transient — wait and let Crossplane re-call. "Resolved, matched nothing" is a real state — the resource was deleted, or its reference is a typo — and usually wants a different response (e.g. a warning, or holding steady rather than waiting). Functions end up reimplementing the same
in-then-getdance. We hit it twice in one project: once gating a hydration Job on an authSecret, and once gating replica placement on a referenced cache being resolvable.How could this Function help solve your problem?
A small helper that classifies a required resource into the three states, so callers don't each re-derive it from the
incheck. Roughly:A list variant (and possibly the same for
require_schema/get_required_schema, which has the analogous distinction) would round it out. Naming/placement and whether this is an enum vs. a small result type are open — happy to send a PR once there's a preferred shape.