Open Pitta opened 2 years ago
FYI I replicated this on latest (0.62.1) with the same config + json payload.
I've seen a customer experience this issue recently as well when sending traces via the Swift SDK, which didn't have the latest proto yet.
This is a bit unfortunate, I can explain why this happens, not sure what is the right behavior:
instrumentationLibrarySpans
was renamed (probably >8 months ago or something like that) to scopeSpans
and the support was removed in v0.58.0 (see https://github.com/open-telemetry/opentelemetry-collector/releases/tag/v0.58.0)instrumentationLibrarySpans
is now an unknown field, and we ignore it and drop it.The combination of the 2 makes this case to return 200. Not sure how based on the current spec we can return a different code.
I think if we returned a useful response body, it'd help. Right now you get 200 OK with an empty response; something like "dropped unknown fields [xxx, yyy, zzz]" would at least give users a clue what was happening.
In the PR that implemented the spec change in the collector we discussed a scenario like this: https://github.com/open-telemetry/opentelemetry-collector/pull/5931. Maybe it's time to allow "strict-enforcement" via https://github.com/open-telemetry/opentelemetry-collector/issues/5935.
I also like the idea of having some important fields, like ResourceSpans and InstrumentationScopeSpans, that are vocal when skipped. This would help users know what's happening.
As discussed in the SIG today, maybe OTLP's partial success response can help here.
As discussed in the SIG today, maybe OTLP's partial success response can help here.
To clarify: for this to work we need to add "accepted" counter to the partial success response.
Describe the bug When sending test traces via
otlp-http
, if the format of the trace is mismatched the server still returns a 200 with no indication of a problem.Steps to reproduce config: BELOW
docker-compose.yaml:
trace.json (from this example)
docker compose up
curl -i http://localhost:4318/v1/traces -X POST -H "Content-Type: application/json" -d @trace.json
What did you expect to see? A 200 response if the trace data was 👍 Anything else with a message mentioning the proto mistmatch
What did you see instead?
What version did you use? Version:
0.60.0
What config did you use?