composable functions with optional arguments lead to duplicate operationId

[baywet]

consider the two follow endpoints:

• /drives/{drive-id}/items/{driveItem-id}/workbook/worksheets/{workbookWorksheet-id}/range(address=''{address}'')/resizedRange(deltaRows={deltaRows},deltaColumns={deltaColumns})
• /drives/{drive-id}/items/{driveItem-id}/workbook/worksheets/{workbookWorksheet-id}/range()/resizedRange(deltaRows={deltaRows},deltaColumns={deltaColumns})

Get the same operation Id: drives.drive.items.driveItem.workbook.worksheets.workbookWorksheet.range.resizedRange

This results in an invalid OAS description.

As far as I know, the only thing that depends on operation ids anymore on our end is PowerShell generation. But this is likely not impacting PowerShell since, as far as I know, we're stripping all functions out when slicing the description for PowerShell.

I believe the solution here would be to come up with a convention when the parameter is expanded, so the first endpoint Id should in fact be something like this:

drives.drive.items.driveItem.workbook.worksheets.workbookWorksheet.rangeByAddress.resizedRange

[irvinesunday]

I think a simpler solution would be to:

1. Identify whether the operation is part of a composable function path.
2. If the above is true, check whether either of the operation segment has parameters
3. If the above is true, create a path hash based on the operation path and add it as a suffix to the operation id. For example, the operation Id of the 1st endpoint could be: drives.drive.items.driveItem.workbook.worksheets.workbookWorksheet.range.resizedRange-d7ec and the second endpoint: drives.drive.items.driveItem.workbook.worksheets.workbookWorksheet.range.resizedRange-a1b3

This will be consistent with how we disambiguate .../$count paths operation ids, for example: /drives/{drive-id}/items/{driveItem-id}/workbook/worksheets/$count --> drives.items.workbook.worksheets.GetCount-98c0