Provide status URL for long running operations

[moserware]

When doing a long-running operation like resourceGroups/X/providers/Microsoft.Web/sites/Y/slots/Z/slotsswap that has a x-ms-request-id, it'd be nice to automatically have the route to get its current status

[davidebbo]

Agreed. I think the more general issue is that when performing Actions, we don't show anything about the Response unless there is an error. We should think through what the UI might look like.

There is also the possibility of doing polling and waiting for completion, but I'm not sure I like that direction as it feels a little too 'high level' for Resource Explorer, which today only does one request at a time.

[moserware]

@davidebbo Thanks for the feedback! I'd be happy with a generic: "You can get status on this request by visiting {{url}}" along with a button to fetch the JSON. It doesn't have to have automatic polling.

As an aside, I asked for this feature because I'm currently stumped on how to fetch the status of a swap. I thought it would have been something like GET https://management.azure.com/subscriptions/{subscriptionId}/operations/{x-ms-request-id} but that didn't seem to work. Would you happen to know what it is?

👏 Thanks for all your great tools: Razor Generator, Kudu, ARMExplorer, etc. It seems that whenever I want to do something interesting on Azure, you're always a few steps ahead of me :)

[davidebbo]

From what I can see, one way to tell is to look at the targetSwapSlot property on either the site or the slot. Normally, they're null. During the swap, they're set to the other slot's name. I'll ask if there is some other way.

[moserware]

@davidebbo Thanks for the workaround idea. I checked it out last night and it seemed to be working (targetSwapSlot would be Production until the swap occurred and then it'd go back to null). This morning, a strange thing has been happening: at first the targetSwapSlot would almost immediately be null and the swap was very fast (and verified the new code in my browser). I tried it a few more times and the targetSwapSlot would be null indicating the swap completed quickly, however when I force-refreshed (ctrl+shift+r in Chrome every second or so), my browser still showed the old code for about 15 seconds (even though targetSwapSlot stayed null).

I would love it if the swap were always near-instantaneous (like it was for a few minutes this morning).

However, to work around this issue it seems like the only way to really check if the swap succeeded is to embed the git hash of the code version under a secret route name and then check if that is different by polling it instead of the status resource route. Am I missing something?

I love the idea of swapping (especially if it was instant), but it seems like I keep having issues with it. I'm going down this path because the autoswap wasn't working consistently (it'd often not swap).

I always appreciate your feedback/advice. Let me know if I should move this discussion to the WebSite/WebApps forums (or elsewhere) instead. I haven't had great success using official channels like support tickets (very slow turnaround time and not very actionable), but it's always refreshing to talk directly to devs like yourself. This issue is partially related to ARMExplorer in the sense of getting proper status, but it's also related to having issues with the swap feature.

[davidebbo]

We're probably getting a little too deep into Swap discussion for the Resource Explorer issue. :) The forum would be the ideal place to discuss and involve all the right experts (some people know more about swap than I do!).

Though I did find out one thing: when you swap, you get an http header back that looks like this:

Location: /subscriptions/{sub}/resourceGroups/Default-Web-NorthEurope/providers/Microsoft.Web/sites/mysite/slots/staging/operations/68126fb2-456b-47ea-8530-b11cd7cd479d

That's the link that gives status on the swap, and is more reliable than the targetSwapSlot workaround.

[moserware]

@davidebbo I'll direct any further problems related to swap specifically to the forums.

I tried to do a GET on the Location header you mentioned that gets returned (using the same Bearer authentication header as I did with the POST to do the swap) and I got back a HTTP 400 (Bad Request) response. Does it work for you? Are you using "https://management.azure.com/" as the base address?

If this pattern is repeated across the APIs (where the Location header has a status URL), then it would indeed be a very helpful feature of ARMExplorer to expose that along with a button to get updated status for long running operations.

Thanks!

[davidebbo]

I tried and it worked fine for me. It returned 202 while ongoing, and then 200 when done. Your best bet to experiment with the API is ARMClient. Use verbose switch to see headers details.

[moserware]

Ah! I added a ?api-version=2014-06-01 at the end of the URL that Location gives (to make it like the URLs ARMExplorer generates itself) and then it worked exactly as you described. Without it, you get the 400 response. If it's not too much trouble, I'd suggest offering this style of URL for non-GET operations that return a Location header.

Thanks for the hint about ARMClient!

[davidebbo]

Agreed, that would make sense.