[typespec/azure-resource-manager] logical result path is undefined in ArmResourceActionAsync

[ArcturusZhang]

When an async operation is performed using Azure-AsyncOperation, the final result of the operation is returned in the properties property in the ArmOperationStatus model, see the standards on ARM RPCs here

For example, when I write:

model Employee is TrackedResource<EmployeeProperties> {
  ...ResourceNameParameter<Employee>;
}

model EmployeeProperties {
  /** Age of employee */
  age?: int32;
}

model Result {
  /** Result of the action */
  result: string;
}

op actionAsync is ArmResourceActionAsync<Employee, void, Result>;

it now gives us:

finalResult: Result
finalEnvelopeResult: Result
envelopeResult: ArmOperationStatus
finalResultPath: undefined

Should we have finalResultPath as properties here?

[allenjzhang]

This sounds like a bug too me. In this standard cases, it should always be properties. Bringing back for discussion

[markcowl]

The ARM RPC does not require that the final result is in the 'properties' property. This is something we would like to get agreement on as a standard in the RPC, and then enforce through TypeSpec, so it is clear to both services and emitters how the lro should be handled on both sides.

In this case, we only provide the information that was provided in Swagger, and depend on the lro algorithm that clients implement to resolve the lro correctly.

Once we get consensus on the RPC standard for Azure-AsyncOperation, we can be much more precise in how we model these APIs, have the templates model the best practice and make it clear to both service and client how the lro is to be handled/supported.

[markcowl]

Resolving this will involve these tasks

• Create a proposed flow for ARM resource operations using Azure-AsyncOperation
• Prototype templates to support this flow
• Get agreement with ARM on this flow as a best practice
• Add this as a 'should' requirement in the RPC
• Release library update and docs for the new Lro pattern