shreemaan-abhishek opened a new pull request, #13690:
URL: https://github.com/apache/apisix/pull/13690
### Description
The `opentelemetry` plugin's `metadata_schema` declared
`additionalProperties` for two objects using forms the JSON Schema validator
does not recognize, so value-type validation was silently a no-op:
- `resource.additionalProperties` used a bare array of schemas:
`{{type="boolean"}, {type="number"}, {type="string"}}`. `additionalProperties`
expects a single schema object, not an array; the validator sees numeric keys
instead of a keyword and ignores it.
- `collector.request_headers.additionalProperties` used `one_of`, which is
not a JSON Schema keyword (the keyword is `oneOf`).
In both cases the constraint had no effect, so `resource` /
`request_headers` values of any type (objects, arrays) passed validation. At
runtime only string/number/boolean values are actually consumed, so non-scalar
values were silently dropped. This has been present since the plugin was
introduced in #6119.
This changes both to the correct `oneOf` form so non-scalar values are
rejected at config time.
### Behavior change
`plugin_metadata` entries whose `resource` or `collector.request_headers`
hold a non-scalar value are now rejected on write and on load. Such values were
already ignored at runtime, so no working telemetry changes; the failure mode
moves from "attribute silently dropped" to "invalid metadata rejected",
consistent with every other schema.
### Tests
Added a test asserting object/array `resource` values and object
`request_headers` values are rejected (400) while scalar values remain valid.
Verified it fails on the current code and passes with the fix.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
