Backend url is overwritten when I only update the specification.yaml file

[anotherRedbeard]

Release version

v4.1.2

Describe the bug

When the specification.yaml file is in the commit without the 'corresponding' apiInformation.json file, the backend url gets overwritten with the url to the apim instance. Then if you try and make a request it will continue to forward requests to itself until the client gives up and cancels the request.

Expected behavior

Only the changes from the specification.yaml file should be published to APIM.

Actual behavior

The backend url is overwitten with the url to the apim instance. See image below:

Reproduction Steps

1. Create a branch
2. Update the description in the specification.yaml file
3. Commit change to branch
4. Create PR from branch
5. Approve/Merge PR

[anotherRedbeard]

@guythetechie I did try this using the Management REST api using just the OpenApi spec "format":"openapi" and got the same result so there might not be anything APIOps can do about it. I'll keep digging though...

[guythetechie]

@anotherRedbeard - just to clarify: are you seeing this issue when there's an apiInformation.json file and a specification file, but only the specification file was modified? In other words, like this:

• artifacts/apis/apiA/apiInformation.json (present in source control, but not part of the commit)
• artifacts/apis/apiA/specification.yaml (modified in the commit)

Or are you talking about cases when there's no apiInformation.json, just a specification file? Like this:

• artifacts/apis/apiA/specification.yaml (modified in the commit)

[anotherRedbeard]

Hi @guythetechie , I'm seeing this issue in the first scenario. In the PR that I created #280 I only applied the fix in that one situation as well.

[anotherRedbeard]

A workaround for now would be to make sure you add the apiinformation.json file to each commit when you change the specification.yaml file and then it will update correctly.

[t0p4]

I faced the same issue, no matter what was changed in the spec file, the url was rewritten

[anotherRedbeard]

@waelkdouh and @guythetechie I created a new PR that doesn't modify the common/http.cs class for your review. #372 .

[Ronbabious]

@anotherRedbeard any news on this? I'm having this issue as well, and wondering if the suggested workaround should still be used

[anotherRedbeard]

@Ronbabious, yes, the suggested workaround should still be used for now. This is in my backlog to create another PR I just haven't had a chance to complete yet.

[waelkdouh]

@Ronbabious we just tested under v6.0.0-rc1 and the issue has been resolved. Please test and let us know.