PropagationSelector JsonSchema derive causes kube-core panic when generating CRD manifests

[daviddahl]

Pre-filing checklist

• I searched existing issues and didn't find a duplicate

Component(s)

Rust OTAP dataflow (rust/otap-dataflow/)

Bug Description

NodeUserConfig gained two new optional fields in #2539 (header_capture: Option<HeaderCapturePolicy> and header_propagation: Option<HeaderPropagationPolicy>). Both fields transitively contain PropagationSelector:

pub enum PropagationSelector {
    AllCaptured,           // unit variant → "all_captured"
    None,                  // unit variant
    Named(Vec<String>),    // tuple variant
}

This enum derives JsonSchema. kube-core's schema generator panics when it encounters a mixed unit/tuple enum because it resolves all_captured as both a plain string and as part of an object subschema in the same oneOf expansion.

Any downstream project that embeds NodeUserConfig in a Kubernetes CustomResource type and calls .crd() to generate a CRD manifest will hit this panic.

Steps to Reproduce

1. Add otap-df-config as a git dependency pointing to any commit from [otap-dataflow] add transport header infrastructure #2539 onwards
2. Define a CustomResource struct with a field of type NodeUserConfig and #[derive(JsonSchema)]
3. Call YourCrd::crd() to generate the CRD manifest

use kube::CustomResource;
use schemars::JsonSchema;
use serde::{Deserialize, Serialize};
use std::collections::HashMap;
use otap_df_config::{NodeId, node::NodeUserConfig};

#[derive(CustomResource, Deserialize, Serialize, Clone, Debug, JsonSchema)]
#[kube(group = "example.com", version = "v1", kind = "MyResource", namespaced)]
pub struct MyResourceSpec {
    pub nodes: HashMap<NodeId, NodeUserConfig>,
}

fn main() {
    let _crd = MyResource::crd(); // panics
}

Expected Behavior

MyResource::crd() generates a valid CRD schema without panicking. PropagationSelector should produce a valid schemars JSON schema compatible with kube-core's schema generator.

Actual Behavior

thread 'main' panicked at kube-core-3.1.0/src/schema.rs:482:29:
Enum variant set [String("all_captured")] has type Single(String)
but was already defined as Some(Single(Object)).
The instance type must be equal for all subschema variants.
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

OTel-Arrow Version

b4867bfc — all subsequent commits on main are affected. Last known working: 8e8dfcf2 (immediately before #2539).

Environment

• OS: Debian bookworm (via rust:1.90.0 Docker image)
• Rust: 1.90.0 (1159e78c4 2025-09-14)
• Cargo: 1.90.0 (840b83a10 2025-07-30)
• kube-core: 3.1.0
• schemars: 1.x

Configuration

[dependencies]
otap-df-config = {
  git = "https://github.com/open-telemetry/otel-arrow.git",
  package = "otap-df-config",
  rev = "b4867bfc"
}
kube = { version = "3.1.0", features = ["derive"] }
schemars = "1"

Log Output

thread 'main' panicked at .cargo/registry/src/index.crates.io/kube-core-3.1.0/src/schema.rs:482:29:
Enum variant set [String("all_captured")] has type Single(String)
but was already defined as Some(Single(Object)).
The instance type must be equal for all subschema variants.
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

Additional Context

The root cause is that PropagationSelector mixes unit and tuple variants, which produces a schemars schema that kube-core's structural schema validator cannot reconcile. A fix would be to add a #[schemars] attribute to PropagationSelector that produces a structurally valid schema — for example #[schemars(untagged)] or a custom JsonSchema impl that emits x-kubernetes-preserve-unknown-fields: true for this field.

Related: the same pattern is already handled for config: Value in NodeUserConfig via #[schemars(extend("x-kubernetes-preserve-unknown-fields" = true))].