Skip to main content

KubeReceiver

Trait KubeReceiver 

Source
pub trait KubeReceiver: Sealed {
    // Required method
    fn field_value(&self, field: &str) -> Option<&Value>;
}
Expand description

Sealed dispatch surface for the value-level primitive receiver-arms — serde_yaml::Value and serde_yaml::Mapping — the two YAML container-shape types every routed value-level two-hop get → as_* primitive (kube_str, kube_u64, kube_bool, kube_seq, kube_map) accepts as its first argument. Where the sibling spec/metadata/root-anchored families always sit on a per-CR &serde_yaml::Value because the outer prelude gates on the document-shape apiVersion + kind + metadata + spec skeleton, the value-level family drops the outer prelude and stays parametric on whichever container-shape the caller already holds — a &Value for a nested-mapping bracket returned from kube_spec_seq_first / kube_seq_first, or a &Mapping for a sub-block already lifted through kube_map / kube_metadata / kube_spec / kube_match_labels. Before this trait landed every caller holding a &Mapping re-inlined the two-line <mapping>.get(<FIELD>).and_then(|v| v.as_<arity>()) chain because the primitive family only accepted &Value — 7 test-side receiver-&Mapping readback sites in caixa-mesh (per-placement.<field> M3 fan-out scalar readbacks on the placement_blocks helper’s Vec<&Mapping> output, per- retry.attempts HTTPRoute mesh-policy overlay readback on the kube_map-lifted retry: sub-block, per-authentication.mode CiliumNetworkPolicy mTLS overlay readbacks on the kube_map- lifted authentication: sub-block) sat on the wrong side of the receiver-arm axis at the same-shape two-hop navigation the &Value- receiver sites already reached through one call.

Sealed via [kube_receiver_sealed::Sealed] so downstream crates cannot extend the receiver-arm axis past the two serde_yaml container-shape types the value-level primitive family walks through — the trait is a substrate-internal dispatch surface, not an authoring extension point. The serde_yaml::Mapping impl exists precisely because serde_yaml::Value::get and serde_yaml::Mapping::get carry the same shape at the same arity (.get(<field>) → Option<&Value>); the trait method field_value is the one-hop navigation the value-level quintet composes on and both serde_yaml types back with an inherent Mapping::get / Value::get call.

Required Methods§

Source

fn field_value(&self, field: &str) -> Option<&Value>

Look up field on the receiver and return the resulting Option<&Value> — the one-hop navigation the value-level primitive quintet (kube_str, kube_u64, kube_bool, kube_seq, kube_map) composes on. Both serde_yaml::Value and serde_yaml::Mapping expose an inherent .get(<field>) returning Option<&Value> at the same shape; this trait method is the dispatch surface the generic primitives call through so a caller holding either container- arm reaches the same one-line dispatch.

Dyn Compatibility§

This trait is dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementations on Foreign Types§

Source§

impl KubeReceiver for Mapping

Source§

fn field_value(&self, field: &str) -> Option<&Value>

Source§

impl KubeReceiver for Value

Source§

fn field_value(&self, field: &str) -> Option<&Value>

Implementors§