[WIP][Feature] Validate enum values in the plugin framework #4478
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes
Many fields in the various requests and responses of the Databricks REST API are enums. Attributes in the TF provider corresponding to enums are string types, and users enter the string value of the enum value that they want to specify. Today, there is no validation that the specified attribute value is actually one of the allowed enum values. This could result in confusing behavior: in SDKv2-based resources, the enum value is likely passed through to the REST API, where it would be considered "UNKNOWN" and likely rejected; and in plugin framework-based resources, the enum value will fail to be converted from the TFSDK structure to the Go SDK.
To provide a better experience, we can validate upfront that the plan only contains valid enum values for such attributes. This way, the failure is much more user-friendly and it happens earlier in the cycle (plan, as opposed to apply).
One key point is that as the API supports new enum values, existing provider versions will no longer be able to use them without upgrading. This may present friction in adoption of new enum values for users. My hypothesis is that this slightly increased friction may be worth the improved user experience.
One point we will also need to verify is that output-only fields (i.e. computed, non-optional, non-required) are still allowed to take on any value (e.g. a
state
attribute if a new state is introduced). There is no point in validating these fields, since users cannot specify them in Terraform, and they are not included in any requests to the REST API.Tests
make test
run locallydocs/
folderinternal/acceptance