Simplify PF attr obj shim

[VenelinMartinov]

We seem to represent list-nested objects in the shim layer differently depending on if it is an attr or block.
The attribute one seems overly complicated: list: {element: schema: element: resource} vs list: element: resource for blocks.

This is an attempt at simplifying it - not fully tested yet.

[VenelinMartinov]

The failing tests even expects this:

pulumi-terraform-bridge/pf/internal/schemashim/custom_type_test.go

Line 113 in 81c9d61

assert.Truef(t, isPseudoResource, "expected shim.Elem() to be of type shim.Resource, encoding an object type")

It says it asserts on type .Resource but actually asserts on .Schema

[codecov]

Codecov Report

Attention: Patch coverage is 69.23077% with 4 lines in your changes missing coverage. Please review.

Project coverage is 60.66%. Comparing base (e46106b) to head (e316c27).

Files	Patch %	Lines
pf/internal/schemashim/attr_schema.go	69.23%	3 Missing and 1 partial ⚠️

Additional details and impacted files

@@                   Coverage Diff                   @@
##           vvm/add_pf_shim_tests1    #2232   +/-   ##
=======================================================
  Coverage                   60.66%   60.66%           
=======================================================
  Files                         356      356           
  Lines                       46447    46459   +12     
=======================================================
+ Hits                        28176    28184    +8     
- Misses                      16711    16714    +3     
- Partials                     1560     1561    +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[iwahbe]

It looks like this change is correct. I'm extremely surprised there are not runtime implications to this.

[VenelinMartinov]

I believe we must have been already handling both as both are present. I'll sit on this for a bit

[t0yv0]

type=6 is TypeMap I think. This looks like the test was expecting what Elem() describes as "single-nested block encoding" - "In this case s.Type() == TypeMap and s.Elem() is a Resource value."

IN the new encoding, this is encoded as TypeList with Elem()=Resource. Elem() doc comment describes that this is an encoding for List-nested block but with this change it also encodes a List attribute.

[VenelinMartinov]

It the old encoding it is List(Elem(Map(Elem(Resource))))

In the new one it is List(Elem(Resource))

Given that pulumi doesn't care about attribute vs block, we might want to encode list nested blocks and list nested objects the same. Both represent an object in a list as far as pulumi is concerned.

[VenelinMartinov]

Also in the old encoding list_nested_attribute and list with object elem are encoded the same. I'm not sure I understand why these would be different to list_nested_block in the shim layer.

[VenelinMartinov]

In the sdkv2 list nested attributes are also represented the same as list nested blocks: #2242

[t0yv0]

Given that pulumi doesn't care about attribute vs block

Are we 100% sure. I was trying to remember if that's the case, can't find anything just now searching now. There is normalizeBlockCollections but it's scoped to sdkv2 "under" the Shim abstraction.

[t0yv0]

Similarly a "single-nested-block-ish" encoding layer is stripped here.

[t0yv0]

Assert on next line interestingly said it expects Resource, but the cast is casting to shim.Schema.

[t0yv0]

This may be a better encoding, but this is pretty error-prone, I wonder if we could complement this with some tests taking this for a spin end to end. Specifically, for tfgen layer and runtime handling:

• is the Pulumi schema generated for these resources what we expect?
• can the bridged provider actually push data through and have it decoded in the PF Create method to match the shape expected by PF

[t0yv0]

Also sounds like an update on the Elem() doc comment is needed here for this case.

[VenelinMartinov]

Yeah, some end-to-end tests are certainly needed - thanks for the suggestions on what to focus on!

I'll also revisit the Elem docs.

[t0yv0]

I expect there is a big encoding bug here somewhere.

Map-nested attributes Map<string,{"x":string}> and single-nested blocks {"x":string} don't have enough in shim.Schema to distinguish them:

https://developer.hashicorp.com/terraform/plugin/framework/handling-data/attributes/map-nested

But they might clobber each other in the shim.Schema representation with Type=TypeMap, Elem()=Resource.

Also in SDKv2 TypeMap, Elem()=Resource means a degenerate case of Map<string,string>. Ideally we cover all these cases and get this right.

[VenelinMartinov]

Also in SDKv2 TypeMap, Elem()=Resource

This is invalid in SDKv2 - only lists and sets can have an Elem Resource

[t0yv0]

IT is admitted though, and valid, per doc in Elem() and https://github.com/hashicorp/terraform-plugin-sdk/blob/main/helper/schema/core_schema_test.go#L220

[VenelinMartinov]

Yup that's true: https://github.com/hashicorp/terraform-plugin-sdk/blob/7e463e46c45e26d5406fe7ff3f497a47122253ea/helper/schema/core_schema.go#L84

[VenelinMartinov]

Wondering if any providers actually use this - I doubt it works well

[t0yv0]

We have to make it an error though, or else to make the schema Map<string,string>, since it's a possibility.

[VenelinMartinov]

Yeah, absolutely, great point about Map nested Resource elems in SDKv2

[t0yv0]

AS time permits, could we rebase on #2456 and have another peek at the interesting bits with the generated Pulumi Schema side-by-side? Could be a good learning experience. Thanks!