Issue with [ApiManagement] / API Version [2022-08-01] - resourcemanager/pollers: LRO URIs of themselves should not be judged entirely based on Path

Is there an existing issue for this?

[X] I have searched the existing issues

Community Note

Please vote on this issue by adding a :thumbsup: reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Service Used

ApiManagement

API Versions Used

2022-08-01

Description

The code in func isLROSelfReference(lroPollingUri, originalRequestUri string) booluses Path to determine whether lroPollingUri is itself, which does not apply to the following situation.

Take creating azurerm_api_management_api with an invalid open api file as an example.

TF config:

terraform {
  required_providers {
    azurerm = {
      source = "hashicorp/azurerm"
      version = "3.98.0"
    }
  }
}

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "test" {
  name     = "exampleRG"
  location = "eastus2"
}

resource "azurerm_api_management" "test" {
  name                = "example"
  location            = azurerm_resource_group.test.location
  resource_group_name = azurerm_resource_group.test.name
  publisher_name      = "pub1"
  publisher_email     = "pub1@email.com"

  sku_name = "Consumption_0"
}

resource "azurerm_api_management_api" "test" {
  name                = "example"
  resource_group_name = azurerm_resource_group.test.name
  api_management_name = azurerm_api_management.test.name
  display_name        = "api1"
  path                = "api1"
  protocols           = ["https"]

  revision            = "1"

  import {
    content_value  = file("api_management_api_openapi.yaml")
    content_format = "openapi"
  }
}

api_management_api_openapi.yam

openapi: 3.0.1
info:
  title: j7t-reproducer-service
  version: "1"
servers:
- url: rest
  variables: {}
tags:
- name: tag
  description: description of tag
paths:
  /document:
    get:
      description: description of operation2
      operationId: operation2
      parameters:
        - description: status
          in: query
          name: status
          schema:
            type: string
            default: P
            enum:
              - PRODUCTIVE
              - ARCHIVED
      responses:
        "200":
          description: get doc by status

lroPollingUri = GET /subscriptions/xxx/resourceGroups/acctestRG-240412104721090643/providers/Microsoft.ApiManagement/service/acctestAM-240412104721090643/apis/acctestapi-240412104721090643;rev=current?api-version=2022-08-01&asyncId=6618a17156773007f83fac9f&asyncCode=201
originalRequestUri = GET /subscriptions/xxx/resourceGroups/acctestRG-240412104721090643/providers/Microsoft.ApiManagement/service/acctestAM-240412104721090643/apis/acctestapi-240412104721090643;rev=current?api-version=2022-08-01

When lroPollingUri and originalRequestUri are as above, TF thinks it is LRO Self Reference and uses originalRequestUri. In fact, the results of using these two URLs are completely different, as detailed below.

Step1: PUT /subscriptions/xxx/resourceGroups/acctestRG-240412104721090643/providers/Microsoft.ApiManagement/service/acctestAM-240412104721090643/apis/acctestapi-240412104721090643;rev=current?api-version=2022-08-01 HTTP/1.1

AzureRM Response:
HTTP/2.0 202 Accepted
...
Location: https://management.azure.com/subscriptions/xxx/resourceGroups/acctestRG-240412104721090643/providers/Microsoft.ApiManagement/service/acctestAM-240412104721090643/apis/acctestapi-240412104721090643;rev=current?api-version=2022-08-01&asyncId=6618a17156773007f83fac9f&asyncCode=201
...

Step2:

Uses lroPollingUri - GET /subscriptions/xxx/resourceGroups/acctestRG-240412104721090643/providers/Microsoft.ApiManagement/service/acctestAM-240412104721090643/apis/acctestapi-240412104721090643;rev=current?api-version=2022-08-01&asyncId=6618a17156773007f83fac9f&asyncCode=201 HTTP/1.1

AzureRM Response:

HTTP/2.0 400 Bad Request
...

{"error":{"code":"ValidationError","message":"One or more fields contain incorrect values:","details":[{"code":"ValidationError","target":"value[0].request.queryParameters[0].defaultValue","message":"Default value must be present in the list of values"}]}}

Uses originalRequestUri - GET /subscriptions/85b3dbca-5974-4067-9669-67a141095a76/resourceGroups/exampleRG23322-0412/providers/Microsoft.ApiManagement/service/example23322-0412/apis/example23322-0412;rev=1?api-version=2022-08-01 HTTP/1.1

Azure Response: 

HTTP/2.0 404 Not Found
...

{"error":{"code":"ResourceNotFound","message":"Api not found.","details":null}}: timestamp="2024-04-12T09:56:58.460+0800"

Therefore, I assume that TF should use lroPollingUri instead of originalRequestUri in this case.

References

Related GH issues:

GH #24379 .
On of the situations in GH #23322 .

hashicorp / go-azure-sdk