Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plugin Framework inconsistent behaviour when trying to rename a schema field nested under a collection #2803

Open
VenelinMartinov opened this issue Jan 2, 2025 · 4 comments
Assignees
Labels
area/tfgen Issues in pkg/tgen, excluding docs generation - use area/docsgen for those kind/bug Some behavior is incorrect or out of spec

Comments

@VenelinMartinov
Copy link
Contributor

VenelinMartinov commented Jan 2, 2025

What happened?

Resources and datasources bridged via the Plugin Framework have a very inconsistent behaviour with ProviderInfo name overrides which prevents provider authors from working around naming issues, for example for pulumi/pulumi#17826

The behaviour is different for properties in datasources versus resources and for each one, the behaviour is different with blocks versus attributes:

Scenario Override Works Error
ListNestedAttribute datasource No No
ListNestedBlock datasource Yes No
ListNestedAttribute resource No Yes
ListNestedBlock resource Yes No

Blocks work correctly but attributes do not. For datasources the failure is silent, while for resource we get an irrelevant error message:

testprovider_attr_res: [{collection} {}]: .Fields should be .Elem.Fields

With the following ProviderInfo override for each:

"collection": {
	Name: "collection1",
	Elem: &tfbridge.SchemaInfo{
		Fields: map[string]*tfbridge.SchemaInfo{
			"prop": {Name: "prop1"},
		},
	},
}

Note that the .Fields property is already on the .Elem, so the error message is incorrect.

Example

ListNestedAttribute datasource schema

Attributes: map[string]dschema.Attribute{
	"collection": dschema.ListNestedAttribute{
		NestedObject: dschema.NestedAttributeObject{
			Attributes: map[string]dschema.Attribute{
				"prop": dschema.StringAttribute{
					Optional: true,
				},
			},
		},
	},
}

ListNestedBlock datasource schema

Blocks: map[string]dschema.Block{
	"collection": dschema.ListNestedBlock{
		NestedObject: dschema.NestedBlockObject{
			Attributes: map[string]dschema.Attribute{
				"prop": dschema.StringAttribute{
					Optional: true,
				},
			},
		},
	},
}

ListNestedAttribute resource schema

Attributes: map[string]rschema.Attribute{
"collection": rschema.ListNestedAttribute{
	NestedObject: rschema.NestedAttributeObject{
		Attributes: map[string]rschema.Attribute{
			"prop": rschema.StringAttribute{
				Optional: true,
			},
		},
	},
}

ListNestedBlock resource schema

Blocks: map[string]rschema.Block{
	"collection": rschema.ListNestedBlock{
		NestedObject: rschema.NestedBlockObject{
			Attributes: map[string]rschema.Attribute{
				"prop": rschema.StringAttribute{
					Optional: true,
				},
			},
		},
	},
}

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 VenelinMartinov added kind/bug Some behavior is incorrect or out of spec needs-triage Needs attention from the triage team area/tfgen Issues in pkg/tgen, excluding docs generation - use area/docsgen for those and removed needs-triage Needs attention from the triage team labels Jan 2, 2025
@VenelinMartinov VenelinMartinov added the p1 A bug severe enough to be the next item assigned to an engineer label Jan 2, 2025
@VenelinMartinov VenelinMartinov self-assigned this Jan 2, 2025
@VenelinMartinov
Copy link
Contributor Author

I've built tests to repro the issue in #2806

@VenelinMartinov
Copy link
Contributor Author

Root-caused to the shim layer mess described in #2231 and #2232

Confirming this fixed the databricks issue...

@VenelinMartinov
Copy link
Contributor Author

VenelinMartinov commented Jan 3, 2025

Databricks is getting other changes to the schema too as a result of the above fix. Something with pluralisation of datasource parameterers. Will try a more direct fix for databricks and revisit this after

@VenelinMartinov
Copy link
Contributor Author

Databricks was unblocked with a patch, removing the P1

@VenelinMartinov VenelinMartinov removed the p1 A bug severe enough to be the next item assigned to an engineer label Jan 3, 2025
VenelinMartinov added a commit to pulumi/pulumi-databricks that referenced this issue Jan 3, 2025
This PR was generated via `$ upgrade-provider pulumi/pulumi-databricks
--kind=provider`.

---

- Updating Java Gen version from 0.20.0 to 0.21.0.
- Upgrading terraform-provider-databricks from 1.58.0  to 1.62.1.
	Fixes #686
	Fixes #681
	Fixes #673
	Fixes #667
	Fixes #648


This PR adds a manual patch to work around an issue with a parameter
named Input which causes a class name clash in C sharp.
This was added instead of a rename does not work due to
pulumi/pulumi-terraform-bridge#2803
The pu/pu issue for the problem is
pulumi/pulumi#17826
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/tfgen Issues in pkg/tgen, excluding docs generation - use area/docsgen for those kind/bug Some behavior is incorrect or out of spec
Projects
None yet
Development

No branches or pull requests

1 participant