No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

This error is now blocking at build time since <https://github.com/pulumi/pulumi-terraform-bridge/pull/1623> but even before the fix this error was present (at runtime) and the listed resources would not provision (pulumi up)

Obviously all objects are resources, which *must* define an ID. That's odd.

The Pulumi resource model requires an identity attribute which by convention it assumes is called "id"

However in some PF based resources in TF there is no ID

Or it's named differently, or has an unexpected type

<https://github.com/pulumi/pulumi-random/issues/607> an issue with RandomBytes led us to this error

RandomBytes has a structural identity based on an attribute called base64..

So, resolution. We now have a ResourceInfo.ComputeID function that's the ultimate tool to resolve these things, it should be able to compute resource identity out of a PropertyMap representing its state

This is how we resolved the problem with RandomBytes.

In case the identity attribute is present but just has an expected name, renaming it to "id" could also work AFIAK.

Let me know if there's any further guidance we can offer on this. Appreciate y'all!

Interestingly  the resource `azapi_resource` does not expose it's ID ("id" field not in schema). Never saw that.

<https://github.com/Azure/terraform-provider-azapi/blob/f4d4045f609cdd2053139b24eac57f6c9dbd5736/internal/services/azapi_resource.go#L422>

Yeah so this one is not affected because its' written against "<http://github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema|github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema>"

The sdk/v2 API bakes in the assumption that every resource has an ID

And this does not require the resource to declare an "id" attribute

So the bridge historically had the same assumption

However it seems than the Plugin Framework brave new world there is no such assumption or Framework API I could call into to recover the identity.

Happy to be corrected if I missed something but it seems to be a genuine change in how they do things now.

So basically for terraform-provider-azapi I'd expect that you can upgrade the bridge just fine and not be affected by this at all (and not get the error). Since the resource is SDKv2 based and not PF based.