Notification Hub Namespaces Delete Future is broken

[tombuildsstuff]

Bug Report

• import path of package in question: github.com/Azure/azure-sdk-for-go/services/notificationhubs/mgmt/2017-04-01/notificationhubs
• SDK version: v18.0.0
• output of go version: go version go1.10.2 darwin/amd64

---

👋

Whilst working on support for Notification Hubs within Terraform - I've noticed the delete future seems to hang for the lifetime of the context passed in, and eventually fails with the following error; but only ~50% of the time.

* azurerm_notification_hub_namespace.test: Error waiting for the deletion of Notification Hub Namespace "acctestnhn-7935624892261362245" (Resource Group "acctestrg-7935624892261362245"): Future#WaitForCompletion: context has been cancelled: StatusCode=202 -- Original Error: context deadline exceeded

In the interim I've worked around this by polling for the Notification Hub Namespace ourselves until we get a 404 (update: maybe not) - but I can't tell if the Swagger or the API needs to be fixed here?

Relevant link from our side:
hashicorp/terraform-provider-azurerm#1589

Thanks!

[marstr]

👋

Doesn't seem like a Swagger error to me! That means @jhendrixMSFT and I are on the case.

Looking at your PR, could you tell me a little bit more about how the ARMClient.StopContext is initialized and what its lifetime looks like? I want to rule out the error your seeing coming from a timeout or cancellation from your Context. :)

[marstr]

If you're pretty confident that ARMClient.StopContext isn't calling for cancellation, then it could be coming from this line: Azure/go-autorest/autorest/azure/azync.go#L168

Mind checking your client's PollingDuration to ensure that it doesn't just need to be increased?

From there we can look into whether or not Future's implementation is being wonky for you.

[tombuildsstuff]

👋🏻 hey @marstr

Sorry I’d meant to provide more info for how we ended up working around this; after some experimentation I noticed if we repeatedly call the Delete method (and then poll ourselves to verify this has gone) this seems to eventually take place, which makes me wonder if this is a service issue instead? Unfortunately I’ve not had time to investigate either way

Hope that helps!

[marstr]

Oh oh, that's very interesting. So I've actually got it backwards (sorry about that), you're not having trouble with premature polling cancellation from the Future. You're having trouble with either:
a) The Future not recognizing that the namespace has indeed been deleted.
b) The namespace just legitimately isn't getting deleted by the service.

[jhendrixMSFT]

I think there's something screwy with the swagger/codegen? I created a simple repro to create a namespace then delete it and the delete times out, plus I still see it in the portal. If I delete it via the portal it takes about a minute or two. So seems like the call to delete isn't really doing anything useful.

[jhendrixMSFT]

Network trace seems to indicate that the portal and SDK do the same thing. When experimenting with my test program I've noticed that sometimes if click on the namespace in the portal while the future is polling the delete succeeds.

[jhendrixMSFT]

@matt-gibbs to summarize, if I create a namespace then delete it the delete never happens and the SDK times out waiting for the async operation to complete. When the DELETE is requested the API returns a 202 (accepted) and polling the URL in the Location header returns status InProgress so it seems like the delete starts but never finishes?

[matt-gibbs]

investigating

[jhendrixMSFT]

@matt-gibbs any update?

[RickWinter]

@matt-gibbs Can this issue be resolved?

[marstr]

Howdy - lot's has changed in the last few years. I actually ended up moving to work for @matt-gibbs on Notification Hubs, before he moved to GitHub.

Without getting into detail - enough has changed in our RP that there's no reason to believe that a bug this old is still applicable. We should close it as stale.

[RickWinter]

Marking this old issue as addressed. If the bug still reproduces on current SDK and service please open a new issue

[ghost]

Hi @tombuildsstuff. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text “/unresolve” to remove the “issue-addressed” label and continue the conversation.

[ghost]

Hi @tombuildsstuff. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text “/unresolve” to remove the “issue-addressed” label and continue the conversation.

[ghost]

Hi @tombuildsstuff, since you haven’t asked that we “/unresolve” the issue, we’ll close this out. If you believe further discussion is needed, please add a comment “/unresolve” to reopen the issue.