[BUG]Empty serviceUrl Causing Deployment Failures

[ehalas]

Release version

v6.0.1.4

Describe the bug

The extraction process is including "serviceUrl": "", which disrupts API deployment during critical situations or version rollback when utilizing the current version.

{"code":"ValidationError","target":"ServiceUrl","message":"The field serviceUrl is invalid."}]}

Expected behavior

The extraction process should disregard "serviceUrl" when it is empty, as the value is considered invalid for publisher (and the field is not mandatory).

Actual behavior

Error when trying to publish the same code extract from production environment.
{"code":"ValidationError","target":"ServiceUrl","message":"The field serviceUrl is invalid."}]}

Reproduction Steps

Extract an API without a serviceUrl value, and attempt to publish any adjustment with this code.

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

[anotherRedbeard]

@waelkdouh and @guythetechie , I can confirm this is an issue. You can get around the validation error by removing the serviceUrl completely (which is what happens when you delete it in the portal and run the extractor), but if you remove the serviceUrl it looks like the APIM base url is getting put back into the serviceUrl similar to the issue we had a while ago: #275

I was not able to find any work arounds to this issue other than populating the serviceUrl with some dummy value as I would speculate the use case for this is setting a backend in a policy instead of using the serviceUrl.

[guythetechie]

Thanks for investigating, @anotherRedbeard. It seems more of an APIM issue than an ApiOps issue. What are your thoughts on how best to handle this? Remove the serviceUrl? Populate it with a dummy value?

[anotherRedbeard]

Just confirmed this is fixed in v7alpha1.0.2. Thanks @guythetechie !

[martin2176]

@guythetechie
cc @anotherRedbeard
Bug 760 was slated to be resolved in v7alpha1.0.2
I tested this in v7.0.0-beta.1.0.0 and it doesn't work as expected.

Here is the scenario and how to reproduce the issue and possible root cause.
Scenario:
I imported an openapi spec petstore 3.x
Went into the APIM - API and cleared out "Web service URL"
Ran extractor . I can see in the extracted apiinformation.json serviceurl is not there.
So far everything look good.
I Publish back the artifact into APIM.
As I trace the API, I can get these steps happening

1. makes a get call to get the DTO object for the API
2. PUT call to API with "serviceUrl": null along with other properties
3. Get call to DTO object. And I can see "serviceUrl": null, in response object
4. PUT call to publish API specification.yaml
5. GET call to get DTO object of API. I can see in the response ""serviceUrl" getting set to apim URL

The issue is; the 4th API call where it PUT API spec, APIM would default serviceurl back to APIM instance URL
I think if you re-order the API call sequence it will work.
Basically the step 2 have to be executed between 4 and 5