Management API role delete returns 200

lilvinz · September 29, 2021, 9:02pm

A successful delete of a role returns http 200 but according to documentation it should return 204. This leads to issues with our automation pipelines.
First time we have seen this broken was 2021/06/30, last time it was good was 2021/06/28.

rueben.tiow · September 29, 2021, 11:16pm

Hi @lilvinz,

Welcome to the Auth0 Community!

After testing this myself, I can confirm your observations. When I try to delete a role, I also receive an HTTP 200 status code response.

Let me check with our Engineering teams on whether this is a bug and clarify what the intended response code should be and if any documentation needs to be updated.

For now, could you please elaborate more on how this led to breaking behavior in your automation pipelines?

Thank you.

lilvinz · September 30, 2021, 9:39am

We are using terraform-provider-auth0 and that fails deleting roles for our review-apps because of the issue i explained. I assume the terraform provider expects the response code to be 204 as it is documented and obviously has been implemented until 2021/06/30. The roles are deleted but the terraform state is kept because of the failure.

github.com/alexkappa/terraform-provider-auth0

Unmarshal error when destroying auth0_connection resources

opened 04:47PM - 03 Jul 20 UTC

closed 05:52PM - 21 Feb 22 UTC

squarebracket

triage preserve

### Description I have created two `auth0_connection` resources, with strategies `auth0` and `google-oauth2`. They create just fine, but when destroying, I get the error: ``` Error: json: Unmarshal(nil) ``` for both of them. The resources are deleted from auth0 but remain in the terraform state, so I'm guessing it's a failure in decoding the API response.  ### Terraform Version ``` Terraform v0.12.24 + provider.auth0 v0.11.0 + provider.aws v2.68.0 + provider.digitalocean v1.20.0 + provider.null v2.1.2 ```  ### Affected Resource(s) * auth0_connection ### Terraform Configuration Files ```hcl resource "auth0_connection" "users" { name = "Development" strategy = "auth0" enabled_clients = [ # list of clients ] } resource "auth0_connection" "google" { name = "google" strategy = "google-oauth2" enabled_clients = [ # list of clients ] options { client_id = "client_id" client_secret = "client_secret" scopes = [ "email", "profile", ] } } ``` ### Expected Behavior The resources are destroyed successfully ### Actual Behavior The resources are deleted from auth0, but the resources remain in the terraform state. ### Steps to Reproduce 1. `terraform apply -auto-approve` 2. `terraform destroy -auto-approve` ### Debug Output This is part of a bigger terraform. I looked through the `TRACE` level logs and didn't see anything relevant.  ### Community Note * Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request * Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request * If you are interested in working on this issue or have submitted a pull request, please leave a comment

rueben.tiow · October 4, 2021, 6:28pm

Hi @lilvinz,

Thank you for your continued patience.

I have an update. After collaborating with our Engineers, they have clarified that ideally, the response code should return 204 as shown in our current documentation.

However, given that it is currently returning 200, we will be updating our documentation to reflect that to prevent any further breaking behavior.

Please let me know if there are any questions.

Thank you.

lilvinz · October 4, 2021, 7:42pm

Thanks for getting back to me. Honestly to me that looks like you broke the API and now you are going to work around that by redefining what is correct.
That does not prevent further breaking behavior at all in my opinion.
Preventing further breaking would be to add a test-case to your test suite which ensures that you don’t accidentally change your API in the future.

rueben.tiow · October 5, 2021, 8:24pm

Hi @lilvinz,

Thank you for your response.

I completely understand your frustration and have passed along this information to our Engineers. Whenever we receive valuable feedback such as this, we try to correct our services as quickly as possible.

We apologize for any inconvenience it may have caused you or your team. Rest assured that we’re taking action to help prevent similar issues from occurring in the future.

Please let me know if there is anything else I can do to help.

Thank you.

system · October 20, 2021, 8:24pm

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.