Cannot set .Elem on a singly nested object block error when upgrading bridge

[VenelinMartinov]

What happened?

The talos provider started getting an error when upgrading the bridge: https://github.com/pulumiverse/pulumi-talos/actions/runs/9934039926/job/27437766510

The error comes from here:

pulumi-terraform-bridge/pkg/tfbridge/info/validate.go

Line 121 in 0e639f6

c.error(path, errElemForObject)

@ringods tried to fix it by removing the .Elem nesting and the types overrides no longer work: https://github.com/pulumiverse/pulumi-talos/pull/99/files#diff-34c57e622183cb0d8dd0d3f9eaa0861b3340120e9b2ad811bac7ac7be4cea4b1

I believe there is something wrong with the code above as it checks for Map nested Resource Elems which is illegal in sdkv2.

• Check if this is the case for PF too.

Example

.

Output of pulumi about

.

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

[VenelinMartinov]

Upstream schema: https://github.com/siderolabs/terraform-provider-talos/blob/d6c2a0bc939de41252d97f09b8e9dfcff3377450/pkg/talos/talos_machine_bootstrap_resource.go#L81

[VenelinMartinov]

Perhaps this is indeed legal in PF: https://developer.hashicorp.com/terraform/plugin/framework/handling-data/attributes/map-nested

Not obvious where the failure is coming from then.

[iwahbe]

I'm marking this as impact/regression and p1 until we can provide guidance on the appropriate next steps for the talos provider.

[t0yv0]

Would be curious on findings here, definitely need to tighten up testing around this.

I recently updated documentation on Elem() to give it some refinement #2187 and some worked out schema examples.

PF allows map-nested attributes indeed, that should project to Map<string, ObjectType>, and it's reasonable to have Elem customizing the ObjectType in this case. The validation code may not take this into account properly. In SDKV2 I don't think it's possible to express something like a map-nested attribute.

[t0yv0]

One wild guess is that map-nested attributes and single-nested blocks are getting confused because they are indistinguishable in shim.Schema.

[iwahbe]

One wild guess is that map-nested attributes and single-nested blocks are getting confused because they are indistinguishable in shim.Schema.

That's very possible 😒, though I'm not sure how we would go about fixing it. The validation is at the level of shim.Schema, not the SDKv{1,2}/PF value.

[t0yv0]

We'd need to extend shim.Schema to contain enough information to distinguish the cases if needed.

[VenelinMartinov]

Did some exploration of the shim layer mapping of pf types here: #2231

map-nested attributes and single-nested blocks

These are indeed identical in the shim layer.

Moreover I am fairly sure the CastToTypeObject function is wrong for PF too, not just for SDKv2: #2231 (comment)