xai-org/x-algorithm · error · anyhow::Error

none of {} LDS resources decoded as Listener

Error message

none of {} LDS resources decoded as Listener

What it means

Raised when a Listener Discovery Service (LDS) response contains resources, but none of them can be decoded as a protobuf Listener message. The code filters resources with Listener::decode(...).ok() and ensures at least one name was extracted; zero names means every decode failed. Typically indicates a type URL mismatch or malformed/foreign resource payload in the xDS response.

Source

Thrown at visibility-filtering/dark_traffic_setup.rs:112

            .into_inner();

        let response = loop {
            let response = stream
                .message()
                .await
                .context("wildcard LDS stream errored")?
                .context("wildcard LDS stream ended without a listener-carrying response")?;
            if !response.resources.is_empty() {
                break response;
            }
        };

        let names: Vec<String> = response
            .resources
            .iter()
            .filter_map(|any| Some(Listener::decode(any.value.as_ref()).ok()?.name))
            .collect();
        anyhow::ensure!(
            !names.is_empty(),
            "none of {} LDS resources decoded as Listener",
            response.resources.len()
        );
        let endpoints: Vec<EndpointInfo> = names
            .iter()
            .filter_map(|name| parse_staging_listener(name))
            .collect();

        if endpoints.is_empty() {
            tracing::warn!(
                listeners = names.len(),
                "dark_traffic: no staging listeners matched"
            );
        } else {
            info!(
                names = %endpoints.iter().map(|e| e.name.as_str()).collect::<Vec<_>>().join(", "),
                "dark_traffic: discovery complete"

View on GitHub (pinned to 24c60942c5)

Solutions

  1. Verify the xDS server's LDS response resource type_url is envoy.config.listener.v3.Listener
  2. Check that the client's Listener proto definitions match the server's version
  3. Dump response.resources type_urls and compare against the expected Listener type
  4. If using a mock server, make it return real Listener-encoded Any values

Example fix

// before
let response = client.fetch().await?; // resources present but not Listeners

// after
for any in &response.resources {
    tracing::warn!("resource type_url={}", any.type_url);
}
assert!(names.iter().any(|n| n == &expected_listener_name));
Defensive patterns

Strategy: validation

Validate before calling

let decodable = response.resources.iter().any(|any| Listener::decode(any.value.as_ref()).is_ok());
if !decodable { return Ok(vec![]); }

Try / catch

Catch anyhow::Error in discover and check for the 'none of {} LDS resources' message; treat as config error, alert, do not retry.

Prevention

When it happens

Trigger: Calling fetch() against an xDS/LDS endpoint whose response.resources are not Listener-typed protos (wrong type_url, delta vs SOTW mismatch, or a test mock returning Any payloads with a different message type).

Common situations: Pointing the visibility-filtering dark traffic setup at a CDS/EDS endpoint instead of LDS; envoy mock servers returning placeholder Any resources; protobuf definition drift between client and server.

Related errors


AI-assisted analysis of xai-org/x-algorithm@24c60942c5 (2026-08-28). Data as JSON: /api/errors/20604ea26810d085. Report an issue: GitHub.