TypeSpec C# emitter doesn't produce LRO method with return type of non-generic Azure.Operation

[devlie]

We are converting our Swagger to TypeSpec, and we have 2 LRO APIs, ImportDevices and ImportUpdate. The newly generated code changes the return type from Operation to Operation<BinaryData> so compilation breaks as it detects breaking change.

• Old Swagger
• TypeSpec
• Generated Swagger

In generated client, I only see this which returns generic Operation:

public virtual Operation ImportDevices(WaitUntil waitUntil, RequestContent content, RequestContext context = null)

dotnet pack would return error:

C:\Users\leolie\.nuget\packages\microsoft.dotnet.apicompat\5.0.0-beta.20467.1\build\Microsoft.DotNet.ApiCompat.targets(82,5): error : MembersMustExist : Member 'public Azure.Operation Azure.IoT.DeviceUpdate.DeviceManagementClient.ImportDevices(Azure.WaitUntil, Azure.Core.RequestContent, Azure.RequestContext)' does
not exist in the implementation but it does exist in the contract. [D:\repos\azure-sdk-for-net\sdk\deviceupdate\Azure.IoT.DeviceUpdate\src\Azure.IoT.DeviceUpdate.csproj::TargetFramework=netstandard2.0] 

There is no way for me to workaround this as I cannot just hand-implement the old method since the method name and signature are identical except the return type.

[m-nash]

@devlie Do the other languages produce the same signature as before? It seems that all languages would hit this issue where getLroMetadata is not returning void as the final result and therefore we are not generator void.

[weidongxu-microsoft]

@devlie

Do you expect "importUpdate" and "importDevices" to have final result?

From your Swagger, "importUpdate" defines an "Update" schema in response https://github.com/Azure/azure-rest-api-specs/blob/main/specification/deviceupdate/data-plane/Microsoft.DeviceUpdate/stable/2022-10-01/deviceupdate.json#L130-L144
while "importDevices" didn't define schema in response https://github.com/Azure/azure-rest-api-specs/blob/main/specification/deviceupdate/data-plane/Microsoft.DeviceUpdate/stable/2022-10-01/deviceupdate.json#L874-L882

PS: Java generated SyncPoller<BinaryData, BinaryData> for both in DPG from Swagger.

[devlie]

Not sure what you mean by final result. From REST API point of view, import update API returns 202 with operation-location header which points to the operation resource. When import is done operation resource would contain a link to the imported update.

For import device operation, IIRC there is no link to imported devices because usually there are too many devices.

[weidongxu-microsoft]

For "importUpdate", I assume you mean this "resourceLocation" which points to the imported update?
https://github.com/Azure/azure-rest-api-specs-pr/blob/0788c5a7d5375a141d66f2cb82266f7c8190550d/specification/deviceupdate/Microsoft.DeviceUpdate/models-update.tsp#L253-L254

[devlie]

For "importUpdate", I assume you mean this "resourceLocation" which points to the imported update?

https://github.com/Azure/azure-rest-api-specs-pr/blob/0788c5a7d5375a141d66f2cb82266f7c8190550d/specification/deviceupdate/Microsoft.DeviceUpdate/models-update.tsp#L253-L254

Correct.

[archerzz]

@devlie You probably need to update typespec definition for import:update. Right now the latest parsing logic cannot find the return type for it. I guess it has something to do how you define resource location.

@markcowl FYI

[weidongxu-microsoft]

@finalOperation(DeviceUpdate.getUpdate) over importUpdate maybe a solution to say an additional request is required for getting final result for importUpdate. Need further investigation/discussion.

[markcowl]

@finalOperation(DeviceUpdate.getUpdate) over importUpdate maybe a solution to say an additional request is required for getting final result for importUpdate. Need further investigation/discussion.

@weidongxu-microsoft There are two ways this can be done:

• If the client is intended to follow the uri returned in UpdateOperation.resourceLocation, then that property should get an @finalLocation decorator, and the property itself should be of type ResourceLocation<T>. This indicates that clients should follow the link returned in this property, and that the finalResult will be T.

Note that, I have added an extra option to the @finalLocation decorator in my upcoming hotfix that allows you to set the intended final result there, without updating the type of the property - this could be a concern because ResourceLocation indicates a url, which is a breaking change from string.

• if the client is just intended to make an additional call to the getUpdate operation, then adding an @finalOperation is appropriate, however, I do not think most DPG clients have this capability. Also, you will need to specify a mechanism for calliung the operation - basically, how the operation paramaters for getUpdate can be filled out from the client, base on the request and response values for the original operation.