The measurements API can return a 202 when there's a partial failure. This is not currently captured by the error handling in the client.
We should probably check for the x-partial-failure header in addition to the response status code, and log or return an error as appropriate; the current behavior is to ignore these partial failures, which leads to the user discovering on their own that the invalid measurements are just missing.
For example, for this post with two measurements, one valid (with a tag) and one invalid:
$ curl \
...
-d '{
"measurements": [{"name": "test", "value": 1, "tags": {"hi":"hi"}},{"name": "test", "value": 2}]
}' -i \
-X POST \
https://metrics-api.librato.com/v1/measurements
HTTP/2 202
...
x-partial-failure: true
x-librato-ratelimit-agg: limit=2400000,remaining=2086687,reset=1515519000
x-librato-ratelimit-std: limit=600000,remaining=353107,reset=1515519000
...
{"measurements":{"summary":{"total":2,"accepted":1,"failed":1,"filtered":0}},"errors":[{"param":"tags","reason":"Must have at least one tag"}]}
The measurements API can return a 202 when there's a partial failure. This is not currently captured by the error handling in the client.
We should probably check for the
x-partial-failure
header in addition to the response status code, and log or return an error as appropriate; the current behavior is to ignore these partial failures, which leads to the user discovering on their own that the invalid measurements are just missing.For example, for this post with two measurements, one valid (with a tag) and one invalid: