You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're using v18.0.0 of the SDK and the package github.com/Azure/azure-sdk-for-go/services/appinsights/mgmt/2015-05-01/insights
What happened?
Prior to ~2018-08-14 the Application Insights API returned a HTTP 200 when an Application Insights Component had been successfully created, as is documented in the Swagger. From around this date onwards the API is now returning a HTTP 201 - which isn't documented in the Swagger (either for v18.0.0, v19.1.0, or the latest branch) - which returns an error from the SDK.
What did you expect or want to happen?
A HTTP 200 should be returned from the API since this is what's documented in the Swagger. Whilst the Swagger could be updated to support returning a HTTP 201 - the API shouldn't return status codes which aren't defined in the Swagger - doubly so when this is a ~3 year old API version which has clients in-use.
We're able to work around this in the short-term by checking for this status code when an error occurs, but the API should be updated to return a HTTP 200 as is documented (rather than patching the Swagger). Given returning a different status code is a behavioural change - I believe that should be made in a new version of the API, so this doesn't break existing clients?
Bug Report
We're using v18.0.0 of the SDK and the package
github.com/Azure/azure-sdk-for-go/services/appinsights/mgmt/2015-05-01/insights
What happened?
Prior to ~2018-08-14 the Application Insights API returned a HTTP 200 when an Application Insights Component had been successfully created, as is documented in the Swagger. From around this date onwards the API is now returning a HTTP 201 - which isn't documented in the Swagger (either for v18.0.0, v19.1.0, or the latest branch) - which returns an error from the SDK.
What did you expect or want to happen?
A HTTP 200 should be returned from the API since this is what's documented in the Swagger. Whilst the Swagger could be updated to support returning a HTTP 201 - the API shouldn't return status codes which aren't defined in the Swagger - doubly so when this is a ~3 year old API version which has clients in-use.
We're able to work around this in the short-term by checking for this status code when an error occurs, but the API should be updated to return a HTTP 200 as is documented (rather than patching the Swagger). Given returning a different status code is a behavioural change - I believe that should be made in a new version of the API, so this doesn't break existing clients?
How can we reproduce it?
Request:
Response:
issue tracking this from our side: hashicorp/terraform-provider-azurerm#1762
The text was updated successfully, but these errors were encountered: