Duplicate operation Ids between PATCH and PUT when both are supported

[baywet]

follow up to #596 and #594

Happens in beta, but will eventually roll out to v1

PUT /servicePrincipals/{servicePrincipal-id}/claimsPolicy

PATCH /servicePrincipals/{servicePrincipal-id}/claimsPolicy

Both have the same servicePrincipals.UpdateClaimsPolicy operation id and they should not.

[irvinesunday]

PowerShell uses these two operation ids but distinguishes them by changing the PUT operation id from servicePrincipals.UpdateClaimsPolicy to servicePrincipals_SetClaimsPolicy. This happens via DevX API during slicing of OpenAPI for PowerShell. Barring the underscore, I wonder if we can rename all PUT operations to xxx.Setyyy ?

[baywet]

As far as I know, PowerShell is the only surface we have that depends on OperationIds. Copilots with Microsoft plugins manifest also use them, but when the manifest is generated from the description, the operation id gets copied and normalized. So any update should flow through.
Can you validate that changing the source won't break PowerShell downstream before proceeding to the change please?

[irvinesunday]

This won't affect PowerShell, because as I mentioned before, we ultimately transform PUT operationIds to use .SetXxx instead of .UpdateXxx via DevX API before consumption by AutoREST.

@timayabi2020 to confirm that this assertion is true, and that the proposed change will not affect PowerShell.

[timayabi2020]

@irvinesunday yes it is true, with that transformation all PUT operations will translate to cmdlets with the verb Set, while PATCH operations will have cmdlets starting with the verb Update.

Using the latest Graph PowerShell installed in your machine, you can confirm the assertion by running the either of these commands.
Find-MgGraphCommand -Command Update-.* | Select Method, Command
Find-MgGraphCommand -Command Set-.* | Select Method, Command

[baywet]

Great! Thanks everyone for triple checking before we make some changes. @irvinesunday good to proceed.