[core-lro] merge azureAsync and location strategies#20656
[core-lro] merge azureAsync and location strategies#20656deyaaeldeen merged 10 commits intoAzure:mainfrom
Conversation
|
This pull request is protected by Check Enforcer. What is Check Enforcer?Check Enforcer helps ensure all pull requests are covered by at least one check-run (typically an Azure Pipeline). When all check-runs associated with this pull request pass then Check Enforcer itself will pass. Why am I getting this message?You are getting this message because Check Enforcer did not detect any check-runs being associated with this pull request within five minutes. This may indicate that your pull request is not covered by any pipelines and so Check Enforcer is correctly blocking the pull request being merged. What should I do now?If the check-enforcer check-run is not passing and all other check-runs associated with this PR are passing (excluding license-cla) then you could try telling Check Enforcer to evaluate your pull request again. You can do this by adding a comment to this pull request as follows: What if I am onboarding a new service?Often, new services do not have validation pipelines associated with them, in order to bootstrap pipelines for a new service, you can issue the following command as a pull request comment: |
|
@jeremymeng Thanks for the approval! Also, FYI I did more work on tests in d8d592d to basically unify the tests for azure-sdk-for-js/sdk/core/core-lro/test/engine.spec.ts Lines 169 to 349 in d8d592d |
Packages impacted by this PR
@azure/core-lro
Issues associated with this PR
Fixes #20647
Describe the problem that is addressed by this PR
The vNext draft of the REST guidelines retires the use of
Azure-AsyncOperationheader in favor ofOperation-Location. For context,Azure-AsyncOperationis mainly used for scenarios where there are two URLs, one for polling (returned in theAzure-AsyncOperationheader) and another to retrieve the resource being created (returned in theLocationheader).What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?
This PR enables clients to use
Operation-Locationfor scenarios whereAzure-AsyncOperationwas used before by merging the logic for handling both into one. The merging was done by augmenting the existing logic for handlingAzure-AsyncOperationas follows: To check if the polling was done (inisPollingDone), also check if the response status code was 202 or an unexpected one:The new merged logic is moved to
locationPolling.tsand the old separate logic for handlingOperation-Locationwas deleted.I am open for alternative approaches, but I believe this is the simplest thing we can do.
Are there test cases added in this PR? (If not, why?)
Yes
Provide a list of related PRs (if any)
N/A
Command used to generate this PR:**(Applicable only to SDK release request PRs)
N/A
Checklists