[BUG][Storage mgmt Track2] RestoreBlobRanges' output TimeToRestore is always 1/1/0001 12:00:00 AM +00:00

Library name and version

Azure.ResourceManager.Storage 1.0.0-beta.9

Describe the bug

In RestoreBlobRanges’ output, no matter what the user input of TimeToRestore is, the output TimeToRestore’s value is always 1/1/0001 12:00:00 AM +00:00. This happens no matter if we put WaitUtil.Started or WaitUtil.Completed when calling the method.

Expected behavior

For RestoreBlobRanges, the TimeToRestore in the output BlobRestoreStatus object should be the same as the TimeToRestore value specified in BlobRestoreContent object when calling RestoreBlobRanges. Say the input is 1/1/2022 15:23:03 AM +00:00, then the output should be the same.

Actual behavior

RestoreBlobRanges’ output TimeToRestore is 1/1/0001 12:00:00 AM +00:00, but the input is not.

The response returned by the server seems to be correct and has the right time:

GET https://management.azure.com/subscriptions/***/providers/Microsoft.Storage/locations/eastus2euap/asyncoperations/97cea899-6954-400d-8ac0-5bbbc547ff10?monitor=true&api-version=2021-08-01 HTTP/1.1
CommandName: Restore-AzStorageBlobRange
ParameterSetName: AccountName
x-ms-client-request-id: ea2a7a0a-d3aa-4912-b4ac-ce1169dc6363
x-ms-return-client-request-id: true
Authorization: Bearer ***
Host: management.azure.com


HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 277
Content-Type: application/json
Expires: -1
x-ms-client-request-id: ea2a7a0a-d3aa-4912-b4ac-ce1169dc6363
x-ms-request-id: 0818c420-1797-4b42-af4e-c0fd775fc311
Strict-Transport-Security: max-age=31536000; includeSubDomains
x-ms-ratelimit-remaining-subscription-reads: 11990
Server: Microsoft-Azure-Storage-Resource-Provider/1.0,Microsoft-HTTPAPI/2.0 Microsoft-HTTPAPI/2.0
x-ms-correlation-request-id: 81c45bec-795f-490f-9564-a2463e1e3e6f
x-ms-routing-request-id: SOUTHEASTASIA:20220609T080208Z:81c45bec-795f-490f-9564-a2463e1e3e6f
X-Content-Type-Options: nosniff
Date: Thu, 09 Jun 2022 08:02:07 GMT

{"status":"Complete","restoreId":"97cea899-6954-400d-8ac0-5bbbc547ff10","parameters":{"timetoRestore":"2022-06-09T07:57:41.3435008Z","blobRanges":[{"startRange":"container1/blob1","endRange":"container2/blob2"},{"startRange":"container3/blob3","endRange":"container4/blob4"}]}}

Reproduction Steps

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

// Wait for result to be returned and check for TimeToRestore value. 
var result = restoreLro.WaitForCompletion().Value;

This is the code we use to reproduce the bug - first call the method with WaitUtil.Started, and then WaitForCompletion. However, if we use WaitUtil.Completed, the bug still exists. Thus it can also be reproduced by

// Wait for it to return and check for TimeToRestore value 
var restoreLro = account.RestoreBlobRanges(
                        WaitUntil.Completed,
                        new Track2Models.BlobRestoreContent(
                            this.TimeToRestore,
                            PSBlobRestoreRange.ParseBlobRestoreRanges(this.BlobRestoreRange))
                        );

Environment

No response

[blueww]

@Yao725 Thanks for the investigation! This works in Track1 SDK, so hope there can be some way to make this also works in Track2. Besides that, we will inform SRP server team about this unalignement.

[Yao725]

@blueww, this can work in track 1 SDK because in track 1 we use Newtonsoft.Json, which is case-insensitive by default. We have changed the SDK code to use timetoRestore in serialization and deserialization and the test records prove it can work. Hope we can resolve this issue in swagger side ASAP.