search

Azure / azure-sdk-for-rust

This repository is for the active development of the Azure SDK for Rust. For consumers of the SDK we recommend visiting Docs.rs and looking up the docs for any of libraries in the SDK.
MIT License
824 stars 289 forks source link

Define Poller in azure_core::http #2458

Open heaths opened 2 months ago

heaths commented 2 months ago

As part of the big refactoring for beta.2, I not only moved the LRO stuff but renamed it. Seems I forgot to move Lro to a Poller object...or maybe we didn't even have that before and needed to implement that yet. All the support types and functions are there.

heaths commented 2 months ago

I'm thinking this is just a custom implementation of a Future where the poll method will use Retry-After or whatever - like we do in other languages - to set a timeout for the waker to poll again. To run the task we can use the task spawner @LarryOsterman wrote.

heaths commented 1 month ago

For reference, legacy generates these each time: https://github.com/Azure/azure-sdk-for-rust/blob/dce289dc72dbe4efbf375f2c6efb6dd1c435e3f5/services/svc/keyvault/src/package_7_5/mod.rs#L1423

Need to prototype some options because I'm not sure if actually defining a Poller<T> that implements Future<T> or IntoFuture<T> really adds anything apart from the ability to hand additional functions off it.

/cc @analogrelay in case she has any thoughts.

analogrelay commented 1 month ago

I do like the idea of being able to directly await a Poller, as long we also properly support cancellation via Drop. That would allow a poller to act like any other future and use all the existing timeout/cancellation patterns in rust.

heaths commented 1 month ago

Good thing to test, yeah (about Drop). As I was thinking about this more this morning, I figured we'd probably construct one much like we do a Pageable<T>, which also takes a couple of functions, and Poller<T> would implement Future or IntoFuture itself.

We should probably implement Future. According to the docs:

Implementing Future is a good choice in most cases. But implementing IntoFuture is most useful when implementing “async builder” types, which allow their values to be modified multiple times before being .awaited.

heaths commented 1 month ago

Talking with @JeffreyRichter about Go's Poller[T], a few things of note:

  1. Do not return the final model. Not only are there many patterns for this across services that make it difficult to support, it's not always possible in some cases e.g., Key Vault's create certificate endpoint.
  2. Allow serialization of the status monitor.
  3. Allow rehydration.
  4. Support customers varying the retry. Probably not worth using our existing RetryOptions, but something probably similar. We should use the retry-after header if services send it. IIRC, there is 1 or 2 custom headers older services may send.