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
- Verify the xDS server's LDS response resource type_url is envoy.config.listener.v3.Listener
- Check that the client's Listener proto definitions match the server's version
- Dump response.resources type_urls and compare against the expected Listener type
- 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
- Log type_url of every xDS resource during integration testing
- Pin proto versions between xDS server and client
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.