Skip to main content

namespaced_dynamic

Function namespaced_dynamic 

Source
pub fn namespaced_dynamic(
    client: Client,
    ns: &str,
    ar: &ApiResource,
) -> Api<DynamicObject>
Expand description

Bind a namespace-scoped Api<DynamicObject> handle from an owned Client + &str namespace + a runtime-resolved ApiResource descriptor.

Owns the 1-link Api::namespaced_with(<client>, <ns>, <&ar>) chain every workspace consumer of a namespace-scoped dynamic typed handle reaches for when the K binding is not known at compile time — the arbitrary rendered-resource axis where K = DynamicObject and the schema is carried by a ApiResource value the caller resolved through crate::process_api / the reconciler’s discovery cache.

§Peer axis

Sibling to namespaced on the (K-slot × runtime-schema-slot) axis pair: namespaced fixes K: Resource<DynamicType = ()> so the K’s schema is statically-known through its Resource impl and no ApiResource slot is required; this primitive fixes K = DynamicObject (whose DynamicType = ApiResource — the schema is carried at the value level) and takes the ApiResource slot explicitly. Both fix the scope at Api::namespaced / Api:: namespaced_with structurally at the function name — a caller writes api::namespaced::<K>(client, ns) for statically-typed K or api::namespaced_dynamic(client, ns, &ar) for the dynamic-object binding, and a regression that silently drifted between them (a stray Api::namespaced_with where a statically-typed handle was intended, an Api::namespaced on DynamicObject that would fail at compile time for want of the ApiResource slot) fails at the callsite’s function-name rather than as silent operator-facing skew.

§Pre-lift call-site history

The 1-link Api::namespaced_with::<DynamicObject>(client, ns, &ar) chain recurred at TWO hand-authored production sites past the ★★ PRIME-DIRECTIVE ≥ 2 duplication threshold, both in tatara-reconciler::ssapply and both feeding a downstream wire-verb dispatch through the DynamicObject typed handle:

  • ssapply::apply_owned — the SSA-side dynamic-object writer for every rendered flux/aplicacao resource. Builds the handle before dispatching through crate::patch::apply to stamp the owned resource under [FIELD_MANAGER].
  • ssapply::fetch — the by-coordinate dynamic-object reader every VERIFY-phase readiness probe + ATTEST-heartbeat drift detector composes to pull the current apiserver-side view of an owned resource. Chains through Api::get_opt(name) to project the 404 → Ok(None) corner.

Both sites restated the SAME 3-arg positional chain verbatim: Api::namespaced_with(client, namespace, &ar) on an owned client: Client + a borrowed namespace: &str + a borrowed &ar: &ApiResource. Post-lift each callsite reads tatara_process::api::namespaced_dynamic(client, namespace, &ar) and the dynamic-object ns-scoped handle binding lives at ONE substrate owner across both consumers.

§Compounding

A future normalization of the dynamic-object ns-scoped handle posture (a wired-in tracing span for handle construction naming the ApiResource’s kind + group, a client-side QPS budget scoped to the discovery-resolved K, a per-namespace retry budget, a fixture-backed client for CI/smoke-tests, a discovery-cache pre-warmer) lands at THIS ONE function and every downstream consumer inherits the upgrade mechanically — no per-site edit at apply_owned / fetch or at future consumers (a future dynamic- object watcher for the P3 kenshi-runner lift, a future kensa audit walker over every rendered resource under a Process, a future drift-probe that fetches by dynamic kind before verifying the attestation root).

The &ApiResource slot is borrowed (matching Api::namespaced_with’s own signature) rather than owned — both pre-lift callsites already build the ar from api_resource(&api_version, &kind)? earlier in the function body and pass it by reference; no consumer needs to consume the descriptor at binding time.

Theory anchor: THEORY.md §VI.1 (generation over composition — the 1-link Api::namespaced_with::<DynamicObject>(<client>, <ns>, <&ar>) chain recurred at 2 hand-authored sites past the ★★ PRIME-DIRECTIVE ≥ 2 duplication trigger and is lifted onto the ONE workspace-wide substrate owner here). THEORY.md §II.1 invariant 5 (composition preserves proofs — the pin block below binds the primitive at fail-before-pass-after granularity, so a regression that drifted the scope slot away from Api::namespaced_with — a stray Api::all_with cluster-wide widening, a bind through the statically-typed Api::namespaced that would fail at compile time for want of the ApiResource carrier — surfaces at api::tests::* rather than as silent operator-facing skew across the two consumer sites).