[Question] Can we reduce the API PUT Parallelism? Publisher is Failing when Tags are in multiple APIs
@guythetechie is already working on this.
Since Jul 5, 2025.
Assessment
This issue has not been assessed yet.
Description
Release version
v6.0.1.7
Question Details
Hi @waelkdouh, I'm running into an issue pushing a suite of APIs up to an APIM instance for the first time after iteratively working through them in the lower env. In the lower env, this error didn't happen because the APIs were pushed at different times. The symptom is an APIM validation error where it says the Tag already exists.
##[error]System.Net.Http.HttpRequestException: HTTP request to URI https://management.azure.com/subscriptions/***/resourceGroups/{RG-NAME}/providers/Microsoft.ApiManagement/service/{APIM-NAME}/apis/{API-ID};rev=1?api-version=2023-09-01-preview&asyncId=686943edfb42681084660528&asyncCode=200 failed with status code 400. Content is '{"error":{"code":"ValidationError","message":"One or more fields contain incorrect values:","details":[{"code":"ValidationError","target":"name","message":"Tag with the same name already exists."}]}}'.
Someone else saw this same validation when doing API pushing using Bicep.
In my case, I have some APIs that are part of a public/private "pair" where the public API has fewer Operations than its private counterpart. But, in the spec, they share the same tags because in the case where the Operation is in both, the operation spec is mostly identical.
My feeling is the Parallelism in the PUT operations is causing APIM to act defensively and is rejecting the PUT because it feels the API-tag already exists.
Can we tell the CLI to do PUTs one at a time? I've not found in the docs whether or not this is possible.
best wishes
Expected behavior
When re-using API Tags in the Operations in a spec and that tag is used in multiple APIs like this:
paths: /: get: tags: - TagName
I'd like to be able to push them without the APIM resource rejecting it with a validation error
Actual behavior
APIM says the tag already exists. I presume because the APIOps CLI sees that it doesn't exist and wants to PUT the api tag but another parallel put has created that tag so the 'if !exists, put new else, update/reuse' logic in the CLI is running into an issue.
Reproduction Steps
I believe to reproduce this you'd use two apis, both sharing API tags and having highly congruent operations but fewer operations in one of them.
- Dominant language
- C#
- Stars
- 448
- Forks
- 247
- PR merge metrics
- No merged PRs in 30d
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.
More from Azure/apiops
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 3/5 1-2 days Newbie friendliness 70/100
-
Difficulty 4/5 3-5 days Newbie friendliness 55/100
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
nightscout/nocturne#1425 ·
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Documentation
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
cake-build/cake#5024 ·
-
Frontend status/draft TechnicalDebt
Difficulty 2/5 1-2 days Newbie friendliness 75/100
Altinn/altinn-auth#4143 ·