[MGMT] discussion, what to improve on LRO in core-v2

[weidongxu-microsoft]

Context / Requirement

LRO in mgmt follows a certain pattern, which is quite different from data-plane.

1. The response of PUT or PATCH is the resource, with provisioningState indicate the LRO state.
2. The response of PUT or PATCH could be 200, with provisioningState=Succeeded (e.g. when the resource exists in backend and there is no difference). In this case, no polling is needed (not GET need to be sent).
3. The id in response of PUT or PATCH is important for customer. They can use it to query the resource. In some case, it can be used to query info related to this resource (e.g. in ARM template deployment, the id is used to query the details of this deployment).

Therefore, mgmt would like

1. Poller can return the response of the PUT or PATCH (the response of the activation/initial operation).
2. API/Poller gives consistence exception (particularly, ManagementException on poller.getFinalResult) when failed to create resource.

Current (v1)

mgmt implemented this design for some LRO APIs

// API, throws com.azure.core.management.exception.ManagementException If fails to create/update resource.
Deployment createOrUpdate(...);
Accepted<Deployment> beginCreateOrUpdate(...);

// interface
public interface Accepted<U> {

    /**
     * Gets the activation response of LRO.
     *
     * @return the activation response
     */
    ActivationResponse<U> getActivationResponse();

    /**
     * Gets the {@link SyncPoller} of LRO.
     *
     * @return the sync poller.
     */
    SyncPoller<Void, U> getSyncPoller();

    /**
     * Gets the final result of LRO.
     *
     * @return the final result.
     * @throws com.azure.core.management.exception.ManagementException If polling fails.
     */
    U getFinalResult();
}

for the LRO PUT/POST/DELETE.
(for DELETE, T=Void)

The getFinalResult() is just a wrapper of getSyncPoller().getFinalResult().
The SyncPoller would throw a ManagementException if LRO is not Succeeded. Otherwise, it be same as typical SyncPoller.

related classes

• Accepted
• ActivationResponse (it is just SimpleResponse + LRO state + retryAfter)
• AcceptedImpl

v2

We'd like to explore

1. Whether we should have such pattern built-in to mgmt codegen
2. Whether we should build the pattern into the subclass of Poller, e.g.

public final class ManagementPoller implements Poller<T, U> {

    public ActivationResponse<U> getActivationResponse();

    ...
}

3. What do we do to POST (resource action)

[github-actions]

Thank you for your feedback. Tagging and routing to the team member best able to assist.

[XiaofeiCao]

I like the ManagementPoller approach.

For POST, I can think of a serializable/deserializable PollingState

• String ManagementPoller.serialize()
• ManagementPoller ManagementPoller.deserialize(String)

something like LRO rehydration. Just a first thought..

[weidongxu-microsoft]

For POST, the major concern from me is that we may not really know the schema of the activation operation. (typespec or swagger can say a schema, but I am not really sure if this is the one returns in runtime service).

So maybe for them we just give simple Poller. However, this would introduce inconsistency in our API.