This Bug Report affects these Traffic Control components:
Current behavior:
When a Federation has zero or more Federation Resolvers assigned (via /federations/{{ID}}/federation_resolvers) the response is wrapped in an extra response/alerts top-level response object like so:
{
"alerts": [
{
"text": "0 resolver(s) were assigned to the dev. federation",
"level": "success"
}
],
"response": {
"response": {
"replace": false,
"fedResolverIds": null
},
"alerts": null
}
}
Note that the response object is at response.response instead of just response, and the response object has the extraneous and undocumented "alerts": null property.
The documented example response does not show this strange nesting, so it's probable that this is a regression bug.
Expected behavior:
The response object should match what is documented, and not wrap what is documented under its own response property.
Steps to reproduce:
- Create a CDN Federation and assign it to your user
topost -kp federations/1/federation_resolvers '{}' (assuming the created Federation's ID is 1).
This Bug Report affects these Traffic Control components:
Current behavior:
When a Federation has zero or more Federation Resolvers assigned (via
/federations/{{ID}}/federation_resolvers) the response is wrapped in an extraresponse/alertstop-level response object like so:{ "alerts": [ { "text": "0 resolver(s) were assigned to the dev. federation", "level": "success" } ], "response": { "response": { "replace": false, "fedResolverIds": null }, "alerts": null } }Note that the response object is at
response.responseinstead of justresponse, and the response object has the extraneous and undocumented"alerts": nullproperty.The documented example response does not show this strange nesting, so it's probable that this is a regression bug.
Expected behavior:
The response object should match what is documented, and not wrap what is documented under its own
responseproperty.Steps to reproduce:
topost -kp federations/1/federation_resolvers '{}'(assuming the created Federation's ID is1).