[Question] Publisher Pipeline is not creating API called 'oauth2', is this is a reserved keyword in apiops

[GaurSumit]

Release version

v5.1.1

Question Details

I am trying to create an API called oauth2 which will acts as a proxy for the actual token URL endpoint from Azure AD. i am seeing a failure when i am trying to publish this new API into my apim instance as looking onto the traces it looks like it is trying to fetch the oauth2 API instead of creating it and since this API does not exist the publisher pipeline is getting failed.

I have tried to create the API manually and it working fine, the API is getting created successfully but from publisher it is not.

Is the Keyword oauth2 is reserved in APIOPS as i was able to create the api manually using the same artefacts i have in my repo.

if you see the below trace it is trying to fetch the API instead of creating it.

2024-07-31T12:28:52.9693796Z info: Publisher[0]
2024-07-31T12:28:52.9695292Z Putting API oauth2...
2024-07-31T12:28:53.0118089Z dbug: GetRestResource[0]
2024-07-31T12:28:53.0119467Z Beginning request to get REST resource at URI https://management.azure.com/subscriptions/***/resourceGroups/***/providers/Microsoft.ApiManagement/service/***/apis/oauth2?api-version=2022-04-01-preview...
2024-07-31T12:28:53.3408459Z crit: Publisher[0]
2024-07-31T12:28:53.3410966Z System.Net.Http.HttpRequestException: HTTP request to URI https://management.azure.com/subscriptions/***/resourceGroups/***/providers/Microsoft.ApiManagement/service/***/apis/oauth2?api-version=2022-04-01-preview failed with status code 404. Content is '{"error":{"code":"ResourceNotFound","message":"Api not found.","details":null}}'.
2024-07-31T12:28:53.3411733Z at common.HttpPipelineExtensions.Validate(Response response, Uri requestUri)
2024-07-31T12:28:53.3412285Z at common.HttpPipelineExtensions.GetContent(HttpPipeline pipeline, Uri uri, CancellationToken cancellationToken)

Expected behavior

• the publisher pipeline should run and create all the artefacts for the oauth2 API.

Actual behavior

• instead of creating the new API, the publisher pipeline is trying to fetch the oauth2 api and since it it not available in the APIM, the publisher pipeline getting failed.

Reproduction Steps

• create an api called oauth2.
• create a post endpoint called 'generate-access-token' which should fetch the token from azure ad using client credentials flow.
• commit the artefacts for api changes into the APIOPS repo.
• run the publisher pipeline to create the API in APIM instance.
• the publisher pipeline would fail trying to GET the API details instead of creating one.

[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.

[guythetechie]

@GaurSumit - do you have an artifacts/apis/oauth2/apiInformation.json file as part of the artifacts that need to be published?

[GaurSumit]

@guythetechie yes the file is present in the repository in the mentioned path.

[guythetechie]

@GaurSumit - I think this was resolved in v6.

In v5, if your apiInformation.json is not part of the commit, we attempt to retrieve some information from the REST API. This can create the problem you're experiencing.

If you're not ready to upgrade to v6, try changing both the apiInformation.json and the specification file. I know you said the apiInformation.json is in your repository, but it also needs to be in your commit.

[GaurSumit]

@guythetechie the file was part of the commit, i had it worked out by reverting the changes and pushing them again as fresh change.

[riosengineer]

@guythetechie - thanks for the info. I am running v6.0.1 and if I update only a specification.json artifact, the publisher will see no change. If I amend the apiInformation.json with some random bogus description text change and update my specification.json the publisher updates correctly.

It seems even in the latest release this is still happening where you need to update both for changes to be published.

[guythetechie]

@guythetechie - thanks for the info. I am running v6.0.1 and if I update only a specification.json artifact, the publisher will see no change. If I amend the apiInformation.json with some random bogus description text change and update my specification.json the publisher updates correctly.

It seems even in the latest release this is still happening where you need to update both for changes to be published.

Sounds like a bug. If you only change the specification.json artifact, the publisher should attempt to process that API. Can you send a sample publisher log where you've only changed the specification.json?

[riosengineer]

@guythetechie - thanks for the info. I am running v6.0.1 and if I update only a specification.json artifact, the publisher will see no change. If I amend the apiInformation.json with some random bogus description text change and update my specification.json the publisher updates correctly.
It seems even in the latest release this is still happening where you need to update both for changes to be published.

Sounds like a bug. If you only change the specification.json artifact, the publisher should attempt to process that API. Can you send a sample publisher log where you've only changed the specification.json?

Log attached. Doesn't pickup anything.
publisher-log.txt

Confirmed the pipeline commit has specification.json changes:

I did some other tests after, saw your comment in this issue and tested it out. It worked, so yeah, maybe a bug. Let me know if I can do anything to help test further? (or if you want me to raise a new issue for this)

[guythetechie]

Thank you, definitely looks a bug. Will prioritize fixing this.

[guythetechie]

@riosengineer - would you mind creating a separate issue to keep things clean? The bug is unrelated to this original issue.