microsoftgraph / microsoftgraph/msgraph-sdk-powershell
Duplicated operaionId
Nobody has claimed this yet.
- Dominant language
- C#
- Stars
- 898
- Forks
- 230
- Avg merge
- 2d 5h
- Merged PRs (30d)
- 31
Description
Describe the bug
Multiple Open API spec has duplicated operaionId
For example:
https://github.com/microsoftgraph/msgraph-sdk-powershell/blob/dev/openApiDocs/v1.0/Users.yml
'/users/{user-id}/photo':
get:
tags:
- users.profilePhoto
summary: Get photo from users
description: The user's profile photo. Read-only.
operationId: user_GetPhoto
parameters:
- name: user-id
'/users/{user-id}/photos/{profilePhoto-id}':
get:
tags:
- users.profilePhoto
summary: Get photos from users
description: The collection of the user's profile photos in different sizes. Read-only.
operationId: user_GetPhoto
parameters:
- name: user-id
When user import Open API spec into product/service. Like Azure API Management will cause conflict
Expected behavior
OperationId should unique.
How to reproduce
- Create Azure API Management service
- Click API, create API from defination
- Paste Open API spec URL, fill the form then press Create
SDK Version
v1.0
Latest version known to work for scenario above?
No response
Known Workarounds
No response
Debug output
Click to expand log
```</details>
### Configuration
_No response_
### Other information
_No response_
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with openApiDocs/v1.0/Users.yml and compare the two user photo paths shown in the report. Trace how these OpenAPI documents are produced, then check whether operationId values are unique across the generated specification. Re-import the corrected specification into Azure API Management to confirm the conflict is gone.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- openapi, yaml
- Domain
- api
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100