[BUG][Stroage mgmt Track2] Cannot get BlobRestoreStatus object from RestoreBlobRanges 202 response

Library name and version

Azure.ResourceManager.Storage 1.0.0-beta.9

Describe the bug

After calling RestoreBlobRanges, as required by the feature team, we need to print the Restore status in Powershell console as soon as we get the first 202 response from the server. With Track2 SDK, we’re not able to easily get the Restore status that’s in the response. That being said, we cannot get the BlobRestoreStatus object which is supposed to be the output of RestoreBlobRanges, from the 202 response.

Expected behavior

When the server returns 202 response, PowerShell should be able to get the BlobRestoreStatus object from the response directly. It’s expected that in Track2 the behavior here should be aligned with that of Track1. The code for Track1 can be found here You can find the PSH code for this API based on track1 SDK here.

Actual behavior

Currently there’s no easy way for PowerShell to get the RestoreId. Instead, the workaround that we’re using right now is to fetch the raw response returned by the api call directly. And then parse the response to get the RestoreId. Dictionary<string, object> temp = (Dictionary<string, object>)restoreLro.GetRawResponse().Content.ToObjectFromJson();

Also, there’s no way to get BlobRestoreStatus object.

Reproduction Steps

Call RestoreBlobRanges with WaitUtil.Started. We cannot get BlobRestoreStatus from restoreLro.

var restoreLro = account.RestoreBlobRanges(
                        WaitUntil.Started,
                        new Track2Models.BlobRestoreContent(
                            this.TimeToRestore,
                            ParseBlobRestoreRanges(this.BlobRestoreRange))
                        );

Environment

.NET SDK (reflecting any global.json): Version: 6.0.300 Commit: 8473146e7d

Runtime Environment: OS Name: Windows OS Version: 10.0.19044 OS Platform: Windows RID: win10-x64 Base Path: C:\Program Files\dotnet\sdk\6.0.300\

Host (useful for support): Version: 6.0.5 Commit: 70ae3df4a6

.NET SDKs installed: 3.1.419 [C:\Program Files\dotnet\sdk] 6.0.105 [C:\Program Files\dotnet\sdk] 6.0.203 [C:\Program Files\dotnet\sdk] 6.0.300 [C:\Program Files\dotnet\sdk]

.NET runtimes installed: Microsoft.AspNetCore.All 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All] Microsoft.AspNetCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 3.1.25 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.NETCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 3.1.25 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.WindowsDesktop.App 3.1.25 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET runtimes or SDKs: https://aka.ms/dotnet-download

[m-nash]

Spoke offline to @tg-msft and @JoshLove-msft I think we are going to go with option 2 given there are a few of these cases out there and that will solve all of them with generated code so no custom code needed when we come across these cases.

[tg-msft]

In data-plane, we do this by customizing the class derived from Operation<T>. That’s closest to Option 1 (not sure if you need the sync/async split since any operation you’d do this for should be buffered?). I don’t think Option 3 is the answer (this LRO looks like a RELO rather than a Status Monitor). I don’t know that we have prior art for Option 2. It’s not a bad idea for RELOs in general, though I’m not sure we have enough metadata to do it automatically.