Incorrect assumptions about SDK-v2 TypeMap encoding

[t0yv0]

Randomized conformance testing has led me to an important corner case for encoding object types in SDKv2 that I
previously misunderstood, it is unfortunately possible that the bridge codebase does not do the right thing here and we
need to take a look and refine the assumptions.

The key code is here: https://github.com/hashicorp/terraform-plugin-sdk/blob/main/helper/schema/core_schema_test.go#L220

Previously I assumed that to encode an object type or a single-nested TF block in schemav2 one would use
Type=schema.TypeMap and Elem=*schema.Resource{}.

However it appears that based on the evidence above, TF in this case would DISCARD the schema supplied in
&schema.Resource entirely and assume this type to be a Map[string]. The cited reason is for compatibility with TF 0.11...

It remains unclear to me how SDKv2 providers encode object types then. It seems from e.g. assumeRoleSchema() in AWS that they use Type=schema.TypeList and Elem=*schema.Resource{} and MaxItems: 1. So that MaxItems is required simply to encode object types. This may be the logical conclusion here.

In terms of the way forward:

• Revise the documentation on schemashim.Elem()
• Ensure that tfgen decides on Map[string] for this case
• Ensure tfgen errors if the user supplies a discarded Resource with TypeMap
  • if the upstream provider supplies a Resource, allow the bridge author to ignore the error
  • otherwise fail hard, we should not have this
• Scan for all runtime usage of the schema for this case
  • tests for makeTerraformInput
  • tests for makeTerraformOutput
  • fix PlanResourceChange code and type inference
  • possibly more

CC @iwahbe @VenelinMartinov

[VenelinMartinov]

CastToTypeObject in

pulumi-terraform-bridge/pkg/tfshim/util/types.go

Line 35 in 89906ef

func CastToTypeObject(tfs shim.Schema) (shim.SchemaMap, bool) {

still suffers from this.

#2180 and #2185 look like consequensces.

Should we revisit this?

#2231 has some more tests around the PF behaviour in the shim layer and the Map type assumption for Objects is not valid everywhere.

[t0yv0]

Yes, M109 perhaps. I did a light pass adjusting docu on Elem() but didn't finish auditing all places that use Elem() to make decisions.