[BUG] Publisher v7.0.0 creates APIs from apiInformation.json but does not import specification.yaml — all APIs created with zero operations"

[hemantmishra726]

Release version

Publisher v7.0.0

Describe the bug

##[error]Unhandled exception. System.Net.Http.HttpRequestException: HTTP request to URI https://management.azure.com/subscriptions/8f1b4de7-0c41-4f8e-b822-72e4f157037c/resourceGroups/AzResourceGpBot/providers/Microsoft.ApiManagement/service/azsiapimnp1cassist/apis/helloworldfromfuncapp/operations/get-httptrigger1/policies/policy?api-version=2024-05-01 failed with status code 400. Content is '{"error":{"code":"ValidationError","message":"Entity with specified identifier not found","details":null}}'.

I am facing this issue, even with the simplest or sample APIs while trying to complete a successful run

Expected behavior

Publisher runs successfully, APIs published along with all operation

Actual behavior

I am able to see APIs being created but no operations added

Reproduction Steps

• task: PowerShell@2
  displayName: Run publisher for ${{ parameters.ENVIRONMENT}} environment
  inputs:
  targetType: "inline"
  script: |
  Set-StrictMode -Version Latest
  $ErrorActionPreference = "Stop"
  $VerbosePreference = "Continue"
  $InformationPreference = "Continue"

   $artifactRoot = "$(Build.ArtifactStagingDirectory)/apim-artifacts"
   Write-Host "[INFO] Looking for API folders in: $artifactRoot"
   if (-Not (Test-Path $artifactRoot)) {
     Write-Host "[ERROR] Artifact root path does not exist: $artifactRoot"
     exit 1
   }
   $foldersToDeploy = Get-ChildItem -Path $artifactRoot -Directory | Where-Object { $_.Name -ne 'Tools' }
   if ($foldersToDeploy.Count -eq 0) {
     Write-Host "[WARNING] No API folders found to deploy in $artifactRoot."
   } else {
     Write-Host "[INFO] API folders to deploy:"
     foreach ($folder in $foldersToDeploy) {
       Write-Host "  - $($folder.FullName)"
       # Log contents inside each main folder (one level deep)
       $subItems = Get-ChildItem -Path $folder.FullName
       if ($subItems) {
         Write-Host "    Contents of $($folder.Name):"
         foreach ($item in $subItems) {
           Write-Host "      - $($item.Name)"
         }
       } else {
         Write-Host "    (Empty)"
       }
     }
   }
   $deployedCount = 0
   foreach ($folder in $foldersToDeploy) {
     Write-Host "[INFO] Deploying folder: $($folder.FullName)"
     # Call publisher or deployment logic here, e.g.:
     # & "$(PUBLISHER_FILE_PATH)" -InputPath $folder.FullName
     # Simulate deployment for logging:
     Write-Host "[SUCCESS] Deployed: $($folder.FullName)"
     $deployedCount++
   }
   Write-Host "[INFO] Total folders deployed: $deployedCount"
   # Print publisher binary path and version/help
   Write-Host "[DEBUG] Publisher binary path: $(PUBLISHER_FILE_PATH)"
   try {
     & "$(PUBLISHER_FILE_PATH)" --version
   } catch {
     Write-Host "[DEBUG] Could not get publisher version with --version, trying --help."
     try {
       & "$(PUBLISHER_FILE_PATH)" --help
     } catch {
       Write-Host "[WARNING] Could not get publisher version or help output."
     }
   }
   Write-Host "[DEBUG] Environment variables:"
   Write-Host "  AZURE_RESOURCE_GROUP_NAME=$env:AZURE_RESOURCE_GROUP_NAME"
   Write-Host "  API_MANAGEMENT_SERVICE_NAME=$env:API_MANAGEMENT_SERVICE_NAME"
   Write-Host "  AZURE_SUBSCRIPTION_ID=$env:AZURE_SUBSCRIPTION_ID"
   Write-Host "  AZURE_TENANT_ID=$env:AZURE_TENANT_ID"
   Write-Host "  AZURE_CLIENT_ID=$env:AZURE_CLIENT_ID"
   Write-Host "  AZURE_CLIENT_SECRET=***"
   Write-Host "  ARTIFACT_ROOT=$artifactRoot"
   
   $publisherOutput = $null
   $publisherError = $null
   Write-Host "Running publisher with: $(PUBLISHER_FILE_PATH) -InputPath $artifactRoot -ResourceGroup $env:AZURE_RESOURCE_GROUP_NAME -ServiceName $env:API_MANAGEMENT_SERVICE_NAME -SubscriptionId $env:AZURE_SUBSCRIPTION_ID -TenantId $env:AZURE_TENANT_ID -ClientId $env:AZURE_CLIENT_ID -ClientSecret ***"
   try {
     $publisherOutput = & "$(PUBLISHER_FILE_PATH)" `
       -InputPath $artifactRoot `
       -ResourceGroup $env:AZURE_RESOURCE_GROUP_NAME `
       -ServiceName $env:API_MANAGEMENT_SERVICE_NAME `
       -SubscriptionId $env:AZURE_SUBSCRIPTION_ID `
       -TenantId $env:AZURE_TENANT_ID `
       -ClientId $env:AZURE_CLIENT_ID `
       -ClientSecret $env:AZURE_CLIENT_SECRET `
       --debug 2>&1
   } catch {
     $publisherError = $_
   }
   Write-Host "[DEBUG] Publisher output:"
   Write-Host $publisherOutput
   if ($publisherError) {
     Write-Host "[ERROR] Publisher error: $publisherError"
   }
   if ($LASTEXITCODE -ne 0) { throw "Running publisher failed with exit code $LASTEXITCODE."}
   Write-Information "Execution complete."
  

  failOnStderr: true
  pwsh: true
  env:
  AZURE_BEARER_TOKEN: $(AZURE_BEARER_TOKEN)
  AZURE_CLIENT_ID: $(AZURE_CLIENT_ID)
  AZURE_CLIENT_SECRET: $(AZURE_CLIENT_SECRET)
  AZURE_TENANT_ID: $(AZURE_TENANT_ID)
  AZURE_SUBSCRIPTION_ID: $(AZURE_SUBSCRIPTION_ID)
  AZURE_RESOURCE_GROUP_NAME: ${{ parameters.RESOURCE_GROUP_NAME }}
  API_MANAGEMENT_SERVICE_OUTPUT_FOLDER_PATH: $(Build.ArtifactStagingDirectory)/apim-artifacts
  ${{ if ne( parameters['API_MANAGEMENT_SERVICE_NAME'], '' ) }}:
  API_MANAGEMENT_SERVICE_NAME: ${{ parameters.API_MANAGEMENT_SERVICE_NAME }}
  ${{ if eq( parameters['COMMIT_ID'], 'publish-artifacts-in-last-commit' ) }}:
  COMMIT_ID: $(Build.SourceVersion)
  ${{ if ne( parameters['CONFIGURATION_YAML_PATH'], '' ) }}:
  CONFIGURATION_YAML_PATH: ${{ parameters.CONFIGURATION_YAML_PATH }}

• script: |
  echo "APIM_NAME: $APIM_NAME"
  echo "AZURE_SUBSCRIPTION_ID: $AZURE_SUBSCRIPTION_ID"
  echo "RESOURCE_GROUP_NAME: $RESOURCE_GROUP_NAME"
  echo "SERVICE_CONNECTION_NAME: $SERVICE_CONNECTION_NAME"
  displayName: 'Print key variable values (publisher-with-env)'

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

What kind of API are you using (WADL, SOAP, OpenAPI, etc)?

[JSchlang]

@guythetechie I am having the same experience. I am using Open Apis, json format. The api deploys successfully but there are no operations. This is also leading to issues with operation policies failing because the operation does not exist. I am on v7.0.0-beta.1.0.0.

[Christian-Kruse-Quibiq]

@guythetechie I have the same experience but only for APIs that contain operations with path parameters. If I remove those operations from the spec file, all operations are created as expected.

[Christian-Kruse-Quibiq]

Tested on both v7.0.0-beta.1.0.0 and v7.0.0-rc.1.0.0

[suzuki-shm]

We may be hitting the same underlying problem.

Environment

• APIOps version: v7.0.0-beta.1.0.0
• OpenAPI parser used by APIOps: Microsoft.OpenApi.YamlReader 3.1.2

Observed behavior

• The publisher workflow completed successfully.
• The changed specification.yaml files were detected.
• The API resource update appeared to succeed.
• However, the deployed API specification in API Management was not updated, and the previous specification remained active.

What we found

In our case, the specification upload was skipped when OpenAPI parsing returned validation errors.

The affected schemas used a discriminator like this:

discriminator:
  propertyName: type

but the schema itself did not declare type in:

required:
  - type

With Microsoft.OpenApi.YamlReader 3.1.2, this produced errors like:

• Schema must contain property specified in the discriminator type in the required field list.

Why the workflow still looked successful

From the APIOps code path, the behavior appears to be:

1. The changed specification.yaml is detected.
2. APIOps tries to parse it.
3. The parser returns validation errors.
4. GetOpenApiSpecification() returns no usable specification.
5. putSpecification() is effectively skipped.
6. The publisher job still finishes successfully.

So the visible result is:

• workflow success
• no clear specification failure in logs
• specification not updated in APIM

How we confirmed it

After adding:

required:
  - type

to the discriminator-bearing schemas, the parser errors disappeared and the specification became deployable again.

Suggestion

It would help if APIOps did one or more of the following when a changed specification.yaml cannot be parsed:

1. Fail the publisher step.
2. Log the parser diagnostics explicitly.
3. Report separately that the API resource update succeeded but the specification upload was skipped.

From our side, fixing the OpenAPI schema resolved the immediate issue, but the silent-success behavior seems to be the larger problem.

[guythetechie]

Thanks all, I've pushed a fix that will be included in our next release.