[Question] Can we reduce the API PUT Parallelism? Publisher is Failing when Tags are in multiple APIs

[erikhjensen]

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.

[github-actions]

  Thank you for opening this issue! Please be patient while we will look into it and get back to you as this is an open source project. In the meantime make sure you take a look at the [closed issues](https://github.com/Azure/apiops/issues?q=is%3Aissue+is%3Aclosed) in case your question has already been answered. Don't forget to provide any additional information if needed (e.g. scrubbed logs, detailed feature requests,etc.).
  Whenever it's feasible, please don't hesitate to send a Pull Request (PR) our way. We'd greatly appreciate it, and we'll gladly assess and incorporate your changes.

[erikhjensen]

I think that what is happening is that if you don't define the tags themselves and have them push, and instead expect that the API Operations will implicitly create the tags when the spec is put then we run into this parallelism issue. I will test whether or not I can mitigate this by pushing the tags separately and then having the spec utilize them.

[waelkdouh]

You are on the right track. Please let us know what your tests return.