Parameters conflict with same name from URL and Body

[stokesy43]

What happened?

I have an issue with trying to create an api release using the Azure Native provider found here

According to the documentation one of the inputs is

[ApiId] string - Identifier of the API the release belongs to.

I have two issues

1. Validation is throwing out the identifier with exception "error: azure-native:apimanagement:ApiRelease resource 'apim-api-release-01' has a problem: 'apiId' is too long (170): at most 80 characters allowed"
2. According to the Azure SDK Rest API specification found here. Both the name and id are required. Name goes in the route and id in the body. This doesn't seem to fit the input model on the resource.

Steps to reproduce

using System.Collections.Generic;
using Pulumi;
using AzureNative = Pulumi.AzureNative;

return await `Deployment.RunAsync(()` => 
{
    var api = new AzureNative.ApiManagement.Api("api", new()
    {
        ApiId = "petstore",
        Format = "swagger-link-json",
        Path = "petstore",
        ResourceGroupName = "rg1",
        ServiceName = "apimService1",
        Value = "http://petstore.swagger.io/v2/swagger.json",
    });

    var apiRelease = new AzureNative.ApiManagement.ApiRelease("apiRelease", new()
    {
        ApiId = api.Id,
        Notes = "yahooagain",
        ReleaseId = "testrev",
        ResourceGroupName = "rg1",
        ServiceName = "apimService1",
    });

});

Expected Behavior

Create an API Release successfully

Actual Behavior

error: azure-native:apimanagement:ApiRelease resource 'apim-api-release-01' has a problem: 'apiId' is too long (170): at most 80 characters allowed

Output of pulumi about

No response

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction. To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[danielrbradley]

I'm currently attempting to recreate this myself but it's taking some time (> 20 mins).

The Id property of the api is the internal identifier of the resource (the full path) rather than just the ApiId property as you inputted it. I'm unsure exactly the relationship between the different arguments but would take a guess that the ApiId input might actually be outputted as the name property. Though I'll see if I can actually create something concrete and confirm.

[danielrbradley]

On your second question:

2. According to the Azure SDK Rest API specification found here. Both the name and id are required. Name goes in the route and id in the body. This doesn't seem to fit the input model on the resource.

It looks like the URL is composed of the following:

/service/{serviceName}/apis/{apiId}/releases/{releaseId}

1. Service is identified by serviceName
2. API is identified by apiId
3. Release is identified by releaseId

It looks like the apiId is also replicated in the request body. However, this should be handled by the Pulumi model poplulating the right fields into the right places.

[danielrbradley]

I've confirmed that using the API name output property resolves this issue.

I also recreated this in TypeScript to ensure the language wasn't a factor:

const resourceGroup = new resources.ResourceGroup("resource-group");

const service = new apimanagement.ApiManagementService("service1", {
  publisherEmail: "[email protected]",
  publisherName: "Pulumi",
  resourceGroupName: resourceGroup.name,
  sku: {
    capacity: 1,
    name: "Developer",
  },
  enableClientCertificate: true,
});

const api = new apimanagement.Api("api", {
  apiId: "petstore",
  format: "swagger-link-json",
  path: "petstore",
  resourceGroupName: resourceGroup.name,
  serviceName: service.name,
  value: "http://petstore.swagger.io/v2/swagger.json",
});

var apiRelease = new apimanagement.ApiRelease("apiRelease", {
  apiId: api.name, // Using name instead of id resolves the issue
  notes: "yahooagain",
  releaseId: "testrev",
  resourceGroupName: resourceGroup.name,
  serviceName: "apimService1",
});

[stokesy43]

Thanks for looking into this and sorry for the late reply but I've had some time off over Christmas.

I did try using the name field but when I did this I got the error

error: autorest/azure: Service returned an error. Status=400 Code="ValidationError" Message="One or more fields contain incorrect values:" Details=[{"code":"ValidationError","message":"Invalid field 'apiId' specified","target":"apiId"}]

I assumed this meant there was an issue with the request hence the bug request. I'm guessing as you've had success that's not the case.

How can I find what is being sent to Azure and the complete response from Azure as sometimes I've found the actual underlying cause is being blocked and only the top level error is being returned.

[stokesy43]

Can I get this re-opened. I've checked the logs and Pulumi is sending the Api Name where it should be sending the Api Id

I0103 10:38:10.184813   15840 eventsink.go:78] eventSink::Infoerr(<{%reset%}>Content-Length: 35
<{%reset%}>)
I0103 10:38:10.184813   15840 eventsink.go:78] eventSink::Infoerr(<{%reset%}>Content-Type: application/json; charset=utf-8
<{%reset%}>)
I0103 10:38:10.184813   15840 eventsink.go:78] eventSink::Infoerr(<{%reset%}>{"properties":{"apiId":"factfind"}}

[danielrbradley]

Do you think this could be a missing output property on the Api resource for the ApiId?

You might be able to work around this for now by manipulating the full resource id of the Api to extract the final section of the URL path.

[danielrbradley]

It looks like this likely stems from a property clash between the URL parameter and body parameter of the same name (apiId).

The one in the URL is specified to be a maximum of 80 characters.

The one in the body is not limited to 80 characters and appears to be expected to be the full resource identifier.

[stokesy43]

Is it possible to get an update on this with an timescale on when this might be fixed?

[danielrbradley]

Unfortunately there's still quite a lot of unknowns to tackle in this issue so it's not a quick change. We need to prove the source of the error (if it is the conflicting names) then find an approach to remedy the issue in a way that won't affect other resources.

If it is related to the conflicting arguments, we might have to introduce a special case for this resource to name the arguments separately then intercept how we map them to the request to Azure.

It might be possible to prove the theory by using verbose logging (pulumi up --logtostderr --logflow -v=9 2> out.txt) and showing how the properties are getting mapping into the request. Unfortunately I can't provide a timescale for being able to commit to further investigation into this issue. If this is an area you'd be interested in contributing to we'd be able to help answer questions along the way.

[eminentspoon]

I am experiencing this exact issue, is there any update on this? I have tested using the Azure Native V2 provider and it is still occurring.