Parseable cannot parse OTLP data without schemaUrl #1751

Activity

1. MatthiasRoels

   added

   bug

   on Aug 12, 2026
2. parmesant commented on Aug 12, 2026

   

   parmesant

   on Aug 12, 2026

   Contributor

   More actions

   Looking at the Rust crate for otel-proto -
   https://github.com/open-telemetry/opentelemetry-rust/blob/48c5637cafcb8cefd26613f5082a2830a56304af/opentelemetry-proto/src/proto/tonic/opentelemetry.proto.metrics.v1.rs#L64

   I guess it is not optional here hence the failure
3. parmesant commented on Aug 12, 2026

   

   parmesant

   on Aug 12, 2026

   Contributor

   More actions

   https://logg.ing/community
   Would love to have a quick chat with you on our Slack 😄
4. MatthiasRoels commented on Aug 12, 2026

   

   MatthiasRoels

   on Aug 12, 2026

   Author

   More actions

   I just joined so you can ping me if you want

   ❤️React with ❤️1Reacted by parmesant
5. DeviousCardi commented on Sep 8, 2026

   

   DeviousCardi

   on Sep 8, 2026

   More actions

   I tried to reproduce this and could not, on the exact image reported (quay.io/parseablehq/parseable:v2.9.4, commit 5acfcb6). Posting what I found in case it helps narrow things down.

   Ingestion succeeds with schemaUrl omitted

   POST /v1/metrics with X-P-Log-Source: otel-metrics, schemaUrl absent at both resource and scope level:

   Payload (schemaUrl omitted everywhere)	Result
   gauge, scope otelcol/prometheusreceiver	200
   sum with exemplars	200
   exponentialHistogram	200

   schemaUrl is already optional at the serde layer

   @parmesant — re: the generated tonic type not being optional, I think the field being String rather than Option<String> isn't sufficient on its own here, because the containing structs carry a container-level #[serde(default)]:

   #[cfg_attr(feature = "with-serde", derive(serde::Serialize, serde::Deserialize))]
   #[cfg_attr(feature = "with-serde", serde(rename_all = "camelCase"))]
   #[cfg_attr(feature = "with-serde", serde(default))]   // <-- makes schemaUrl optional
   #[derive(Clone, PartialEq, ::prost::Message)]
   pub struct ResourceMetrics { /* ... schema_url: String ... */ }

   That attribute is present on every struct that has a schema_url field in the enabled feature set (ResourceMetrics, ScopeMetrics, ResourceLogs, ScopeLogs, ResourceSpans, ScopeSpans), so a missing schemaUrl deserializes to an empty string rather than erroring.

   A direct check against the crate, independent of Parseable:

   opentelemetry-proto 0.32.0 -- schemaUrl OMITTED:
     [OK] MetricsData
     [OK] LogsData
     [OK] TracesData
   

   This also isn't a version-skew issue: the same #[serde(default)] is present in 0.30.0, and opentelemetry-proto was pinned to 0.32.0 from crates.io in 653c303 (2026-06-17), which predates the v2.9.4 tag (2026-07-11).

   What would help

   Since the failure is real for @MatthiasRoels but not triggered by a spec-shaped payload, the deciding input is the actual bytes on the wire. Could you capture the exact request body that produced

   Could not deserialize into JSON object, missing field `schemaUrl`
   

   for example via a debug exporter or logging exporter on the Collector alongside the OTLP one, or a file exporter? A minimal failing payload would make this a quick fix. It's also worth confirming the running image digest, in case the deployed build differs from the v2.9.4 tag.

   Happy to put up a PR once there's a payload that reproduces.