Using `stream-style-serialization: true` for Assistants

[jpalvarezl]

Follow up issue on this PR https://github.com/Azure/azure-rest-api-specs/pull/27683

We should include the option stream-style-serialization: true in the tspconfig.yaml file in the spec.

Also remove enable-sync-stack: true as that is the default value for the flag.

I will add more details when I have them.

[weidongxu-microsoft]

Please wait a bit for typespec-java 0.14.0 (it should set stream as default)

Current version of typespec-java probably pretty buggy (Alan and us fixed lots of issues since then -- but could be more -- this option is not widely used yet)

Not sure about "Polymorphic types" in the PR. "FunctionToolCall.java" disappeared?

[weidongxu-microsoft]

I've tried converting tsp lib to stream-style-serialization (twice), latest here https://github.com/Azure/azure-sdk-for-java/pull/39287

Assistants appears good, but there is still issues on other libs.

[weidongxu-microsoft]

blocked by this issue https://github.com/Azure/autorest.java/issues/2629

assistant has API that returns a JSON array

    public List<OpenAIFile> listFiles(FilePurpose purpose) {
        RequestOptions requestOptions = new RequestOptions();
        if (purpose != null) {
            requestOptions.addQueryParam("purpose", purpose.toString(), false);
        }
        return listFilesWithResponse(requestOptions).getValue().toObject(FileListResponse.class).getData();
    }

And the de-serialization would have problem in runtime https://dev.azure.com/azure-sdk/public/_build/results?buildId=3637219&view=logs&j=6c7f083d-ff58-51f0-96fc-ee802c31977a&t=14db3085-f2ce-5564-d924-c3d252922b7e&l=9677

core is not able to know that OpenAIFile within the List should de-serialize via azure-json (currently runtime goes with Jackson, hence the error).

[weidongxu-microsoft]

Another issue https://github.com/Azure/autorest.java/pull/2556#issuecomment-2019562804

I think it is due to incorrect typespec.

[jpalvarezl]

blocked by this issue https://github.com/Azure/autorest.java/issues/2629 assistant has API that returns a JSON array

public List<OpenAIFile> listFiles(FilePurpose purpose) {
    RequestOptions requestOptions = new RequestOptions();
    if (purpose != null) {
        requestOptions.addQueryParam("purpose", purpose.toString(), false);
    }
    return listFilesWithResponse(requestOptions).getValue().toObject(FileListResponse.class).getData();
}

And the de-serialization would have problem in runtime https://dev.azure.com/azure-sdk/public/_build/results?buildId=3637219&view=logs&j=6c7f083d-ff58-51f0-96fc-ee802c31977a&t=14db3085-f2ce-5564-d924-c3d252922b7e&l=9677

core is not able to know that OpenAIFile within the List should de-serialize via azure-json (currently runtime goes with Jackson, hence the error).

I think the unit tests for this are passing, but maybe I am not understanding the issue you mention here @weidongxu-microsoft . Here we actually deserialize into a private type that has no generic parameters (FileListResponse) and then we simple expose one of its members with getData().

[jpalvarezl]

Another issue https://github.com/Azure/autorest.java/pull/2556#issuecomment-2019562804

I think it is due to incorrect typespec.

@weidongxu-microsoft , Could you elaborate a bit on what we would need to do differently if it's our definition that is wrong?

I tried defining a custom scalar and making that nullable instead: (as you suggested in this PR)

@encode(DateTimeKnownEncoding.unixTimestamp, int32)
scalar otherEpochDateTime extends utcDateTime;

But it still results in the same parsing error in Java.

[weidongxu-microsoft]

I think the unit tests for this are passing, but maybe I am not understanding the issue you mention here @weidongxu-microsoft . Here we actually deserialize into a private type that has no generic parameters (FileListResponse) and then we simple expose one of its members with getData().

Thanks. It should work fine if the wire type is not generic.