[Bug]: sharedRoute openapi operationId issue

[csaba-veezla]

Describe the bug

We have a use case where you can create assets in our system; the source of an asset can differ.
So for the same endpoint, we support both "multipart/form-data" and "application/json" as content types.

The two operations are slightly different from each other, so we are leveraging the @sharedRoute operator.
The issue comes from the open API emitter. It concatenates the operationIds, and the resulting operationId is rarely unusable for the client code generation.

typespec/packages/openapi3/src/openapi.ts

Line 687 in fef1c39

operationId: operations.map((op) => resolveOperationId(program, op.operation)).join("_"),

As you can see in the playground, it will result in the following shared operationId: Assets_createAsset_Assets_createAssetWithUpload or createAsset_createAsset if you had set the individual operations to createAsset.
Afterward, this will result in something similar in the generated code as well.

I see 2 solutions to this problem:

• Either it should run a unique on that operations.map, so if all the shared operations have the same operationId, the shared id will be the same.
• Alternatively, it checks if the shared operations have a provided operationId and it joins the the ones that have some, or if there is none, it generates the one that it does right now (mostly will result in the same json as it does now, backward compatible)

Reproduction

I tried to reduce the code to the minimum, but I couldn't make the operationId decorator work, it should be part of the @typespec/openapi3 lib, so I'm not sure, what I am missing:

playground

Checklist

• Follow our Code of Conduct
• Check that there isn't already an issue that request the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion.
• The provided reproduction is a minimal reproducible example of the bug.