[Epic] Implement the new LRO from core to codegen

[qiaozha]

Tasks

Beta Give feedback

1. [core-lro] Summarize the user scenarios and re-design poller interfaces for better experience azure-sdk-for-js#28029
   Azure.Core +1
   
2. Support sync poller & new lro in core-lro azure-sdk-for-js#28051
   Azure.Core +1
   
3. Implement Modular for new LRO support #2166
   HRLC Mgmt p0 +3
   
4. Implement Modular for restorePoller #2231
   HRLC priority-0 +2
   
5. How to deco beginXXX?
6. Implement new LRO in RLC #2230
   0 of 2
   RLC p0 +2
   
7. Implement RLC for restorePoller
8. Add migration guide for customers from v2 to v3 azure-sdk-for-js#29703
   Mgmt +1
   
9. Support abortSignal for LRO operations in HLC

[MaryGao]

High level design: https://gist.github.com/joheredi/09b81c192e8c7c4ee3581ac0b9f76c12
Detailed design: loop's doc

[MaryGao]

Share MOM for detailed design meeting at Dec 7th:
What is the naming convention for LRO operation?
The name would be the same as defined one in TypeSpec and no extra prefix or suffix e.g beginXXXX.

Do we initiate the request when getting the poller?
Yes.

What if the initial request throws exception but customers won't await that?
The exception will not happen when creating the poller but customers would receive that exception finally via await, poll, pollUntilDone or serialize.

Do we need to keep the poller's state up-to-date by triggering polling automatically?
No.

Do we need to include one-time poll in getOperationState and other sync methods?
Yes, we agree that having an one-time poll to fetch the latest status. But in current implementation we mixed the poller state and operation status and we prefer to re-design to simplify the usage. Mary and Deya would follow on this.

Is it worth a breaking change for core-lro?
Not yet finalized. Mary will work with Deya to review the current scenarios. We need to rethink if the current interfaces could adopt to these scenarios and also satisfy our new design. Then evaluate if it is worth a breaking with new proposal.

How do we want the serialization and rehydration experience when the initial request has not yet returned?
We prefer option 2 – add a serialize function. It depends on whether we have a core-lro breaking, if yes we would deco toString; if no we would throw exceptions in toString.

Will we accept the breaking changes for customers who migrate from HLC to Modular?
Yes, we accept the breakings.

Will we adopt for poller & promise change for RLC helper?
Yes, we prefer to adopt sync creation of poller. Also Mary would review the customer usage scenarios and based on that proposing new helper name.

How to support Paging & LRO operation?
There would be two options for public API. Considering this is an advanced case, Mary would collect the real case and offline confirm with the team for the final decision.

Will we generate polling operation defined in tsp @pollingOperation?
Yes, we agree that we prefer exposing the polling operation in JS. We don't want to hide any secrets from our customers and consistency with other languages is not our top priority. But we could wait the arch board review then offline double confirm it with team.

How to improve the resumeFrom experience?
Not yet finalized. resumeFrom based on original method would require operation params when rehydrating. One proposal is having a generic restorePoller helper. Mary and Deya would work on new design for better user experience.

[MaryGao]

Follow up design meeting and see comment Azure/azure-sdk-for-js#28029 (comment)

[joheredi]

The only remaining task in this epic is P1 so I'm downgrading this epic to p1

[MaryGao]

@joheredi Any feedbacks from JS archs for v3 API view?

[qiaozha]

should we resolve this #2394, make sure there's no changes in the core-lro side before v3 GA?

[MaryGao]

yeah i think so i added it into our first iteration.

[MaryGao]

We scoped this Epic to new LRO preview version. So the only remaining work would be

• upgrade to latest preview

And the GAed task would be in #2565.

[MaryGao]

Close as upgrading to stable now.