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.

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

Allow status of backup and restore operations to be queried #15067

Closed
heaths opened this issue Sep 10, 2020 · 4 comments
Closed

Allow status of backup and restore operations to be queried #15067

heaths opened this issue Sep 10, 2020 · 4 comments
Assignees
Labels
Client This issue points to a problem in the data-plane of the library. KeyVault

Comments

@heaths
Copy link
Member

heaths commented Sep 10, 2020

To facilitate long-running backup and restore operations, provide idiomatic APIs to query status. This may be on the KeyVaultBackupClient directly, or on public operation classes.

@heaths heaths added Client This issue points to a problem in the data-plane of the library. KeyVault labels Sep 10, 2020
@heaths heaths added this to the [2020] October milestone Sep 10, 2020
@christothes
Copy link
Member

The possible statuses are InProgress, Succeeded, and Failed. IMO, The idiomatic mechanism to query status of an operation utilizing the standard set of properties is as follows:

  • Evaluate the HasCompleted property of the operation
    • If true
      • Status = Succeeded: evaluating the Value property returns the result of the operation
      • Status = Failed: evaluating the Value property throws
    • If false
      • Status = InProgress
  • Operation started in some other context
    • Hydrate the operation, given the Id of a previously started operation with this ctor
    • rules above apply

@heaths Were you thinking we should extend the operation classes to represent status more explicitly?

@heaths
Copy link
Member Author

heaths commented Sep 14, 2020

I should've been more clear. We need to expose a way to get the long-running Operation<T> classes after the fact, e.g. if the application was shut down but later restarted and needed to query status. The CertificateOperation in Certificates allows this via a constructor, taking the CertificateClient and certificate name. Something like that could be an option here as well.

@christothes
Copy link
Member

I should've been more clear. We need to expose a way to get the long-running Operation<T> classes after the fact, e.g. if the application was shut down but later restarted and needed to query status. The CertificateOperation in Certificates allows this via a constructor, taking the CertificateClient and certificate name. Something like that could be an option here as well.

Perhaps I am missing something, but don't we have that here?

@heaths
Copy link
Member Author

heaths commented Sep 14, 2020

Maybe this didn't need opened then when I was doing all the langs - might've just been in err. However, those parameters need to flip. Client should go first, but I already opened a bug on that: #15065. Please make sure the restore operation is comparable.

@heaths heaths closed this as completed Sep 14, 2020
@github-actions github-actions bot locked and limited conversation to collaborators Mar 28, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Client This issue points to a problem in the data-plane of the library. KeyVault
Projects
None yet
Development

No branches or pull requests

2 participants