docs(core): add an example of custom polling

[archerzz]

• add a sample case in OperationSamples
• add a section Custom polling for completion of operation in document

resolve #29072

Contributing to the Azure SDK

Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.

For specific information about pull request etiquette and best practices, see this section.

[archerzz]

We've been contact for several times regarding custom polling. So, it would be better we add an example in our document.

[azure-sdk]

API change check

API changes are not detected in this pull request.

[annelo-msft]

I'm curious how broadly this approach has been agreed upon. We shouldn't provide a sample to the Azure.Core docs for something we don't recommend for all of Azure.Core.

[archerzz]

I'm curious how broadly this approach has been agreed upon. We shouldn't provide a sample to the Azure.Core docs for something we don't recommend for all of Azure.Core.

@annelo-msft We have been contacted at least twice for customer cases (@m-nash and me respectively). The solution from SDK side is to customize the polling behavior. In my case(#29072), the Retry-After header is not correctly set, so basically the service is asking the clients to DDos itself. In current implementation of mgmt track2 polling, the TimeSpan parameter in WaitForCompletion actually doesn't work. So previously I thought we should make the user input TimeSpan work for some cases, so that the customers can input a big value to avoid huge traffic to the server side (it's just a remediation).

But after discussion, we thought it might be better to let users fully control the polling since we cannot foresee all edge cases.
The capability provided by Azure.Core is better than track1 in which it's hard to customize your own polling behavior. I thought it is useful, though not realized that it's not recommended :)

[ghost]

Hi @archerzz. Thank you for your interest in helping to improve the Azure SDK experience and for your contribution. We've noticed that there hasn't been recent engagement on this pull request. If this is still an active work stream, please let us know by pushing some changes or leaving a comment. Otherwise, we'll close this out in 7 days.

[ghost]

Hi @archerzz. Thank you for your contribution. Since there hasn't been recent engagement, we're going to close this out. Feel free to respond with a comment containing "/reopen" if you'd like to continue working on these changes. Please be sure to use the command to reopen or remove the "no-recent-activity" label; otherwise, this is likely to be closed again with the next cleanup pass.

[nishanthm-msft]

Hi, we are migrating from Track 1 to Track 2 SDK. I need to track a long running operation in an async manner using its operation Id. It would not be feasible to wait synchronously for the LRO to complete. So, we do not want to wait until completion (synchronously) and rather would need to jump to do other tasks meanwhile the LRO is going on and come back and be able to poll the operation status and act accordingly.

We were able to do this in Track 1 SDK using https://github.com/Azure/azure-sdk-for-net/blob/main/sdk/recoveryservices-backup/Microsoft.Azure.Management.RecoveryServices.Backup/src/recoveryservicesbackup/Generated/BackupOperationStatusesOperations.cs#L92 where the LRO status could be polled using its Operation Id. But similar functionality is not available in Track 2 SDK.

This is a useful functionality and can this be addressed in Track 2 SDK?

[m-nash]

@nishanthm-msft are you doing this within the same process? If so you can store the ArmOperation objects you get back and periodically call UpdateStatus on them to see if they are finished.

If you are doing this across processes then yes you will need to send the Id property to the other process so that it can rehydrate the LRO and pick up where it left off which is the process that is not complete yet.

[nishanthm-msft]

@nishanthm-msft are you doing this within the same process? If so you can store the ArmOperation objects you get back and periodically call UpdateStatus on them to see if they are finished.

If you are doing this across processes then yes you will need to send the Id property to the other process so that it can rehydrate the LRO and pick up where it left off which is the process that is not complete yet.

@m-nash I am doing this across processes. So, the process which executes this operation is actually different from the one tracking it. Can you please share your thoughts on the below approach which I thought could serve the purpose.

Can we pass the reference of the entire ArmOperation object itself as it is (instead of Id alone as rehydration isn't available yet) that we get back from the process executing this LRO to the calling process and then later poll the status of the LRO when required from the calling process itself using UpdateStatus?