Invalid `operationIds` for certain OData functions under `reports`.

[peombwa]

Describe the bug
Certain operationIds for OData functions under reports entitySet have a weird suffix to them e.g., reports_getSharePointSiteUsageDetail-204b.

To Reproduce
Steps to reproduce the behavior:

• Go to https://graphexplorerapi.azurewebsites.net/openapi?tags=reports.Functions&openApiVersion=3&graphVersion=v1.0&format=yaml&style=PowerShell
• Inspect the returned OpenAPI document.
  

Expected behavior
OperationIds should match the function names in the OData metadata.

[darrelmiller]

Possible suggestion: Could we add WithDate and WithPeriod to the end of the OperationId? i.e. we use the set of parameter names as a unique suffix. (or maybe ByDate or ByPeriod)

[irvinesunday]

@peombwa the suffix after the operationId is a hash value of the function name. This is appended to the operationIds of two or more overloaded Functions so as to avoid duplicates.

@darrelmiller some functions are parameter-less, so the option of using parameter name might not be feasible.

Does PowerShell care much about this suffix or the naming of this suffix. If not, we can just remove these suffixes in the DevX API when processing the subset OpenAPI documents.

[darrelmiller]

@irvinesunday If the function is parameterless then there will not be a name clash. OData requires the parameters to disambiguate between function names. Therefore if there are no parameters then no suffix is required.

[peombwa]

@irvinesunday, is there a reason we need the hash to disambiguate duplicate operationIds? Having GET operations that have duplicate operationIds and different parameter names is not an issue in PowerShell. AutoREST will generate an overload (parameterSet) if the operationIds are identical and the parameters are different.

AutoREST will only fail if the operationIds are identical and:

• The operations with duplicate operationIds have the same parameter names + type.
• The operation is PUT, PATCH, or POST (anything with a body in the request). So, OData actions will fail.

In this case, by dropping the hash suffix from GET operations, I can generate PowerShell commands for the functions above successfully as shown below:

[irvinesunday]

Since the hash prefix is only appended to the operationIds of paths with overloaded functions, and functions expose only GET operations, going by the conditions that @peombwa has outlined that would lead to AutoREST failing in the case of duplicate operationIds then I think it would be best to strip out the hash suffix from operationIds in DevX API when serving subset OpenAPI docs for the PowerShell style option.

[peombwa]

@irvinesunday, the proposal sounds good to me. Keep me in the loop when the change is ready for testing.