Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add documentation for LRO rehydration #7261

Closed
wants to merge 1 commit into from
Closed

Add documentation for LRO rehydration #7261

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
13 changes: 13 additions & 0 deletions docs/general/design.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -370,6 +370,19 @@ Polling configuration may be used only in the absence of relevant retry-after he

{% include requirement/MUST id="general-lro-progress-reporting" %} expose a progress reporting mechanism to the consumer if the service reports progress as part of the polling operation. Language-dependent guidelines will present additional guidance on how to expose progress reporting in this case.

### Rehydration for long running operations

After a long running operation initialized, the user might want to rehydrate a client to get the status of the operation in a different process or server.
And there are circumstances, the user might want to rehydrate the operation with a difference language SDK other than the initialization language SDK.
To achieve this, we need to return a rehydration token for later cross-language rehydration.
The rehydration token should contain below information:
- HeaderSource: Indicates where the NextRequestUri locates in the initial response header, it could be `OperationLocation`, `AzureAsyncOperation`, `Location` or `None`
- NextRequestUri: The Uri to poll status of the operation
- InitialUri: The initial Uri of the operation
- RequestMethod: Http request method of the operation
- LastKnowLocation: The last known `Location` value in the response header
- FinalStateVia: Configuration from API spec, it could be `AzureAsyncOperation`, `Location`, `OriginalUri` or `OperationLocation`

## Repeatable requests

The ability to retry failed requests for which a client never received a response greatly simplifies the ability to write resilient distributed applications. When the method on the service is not idempotent, the service may support safe retry by supporting repeatability headers as defined in [OASIS Repeatable Requests Version 1.0](https://docs.oasis-open.org/odata/repeatable-requests/v1.0/repeatable-requests-v1.0.html).
Expand Down