Update SDK API to 9718484d914270778e25e06040a5b3a17e19a7f7#5773
Conversation
SDK v0.140.0 adds DeploymentId and VersionId to PipelineDeployment, so the read-back deployment block now contains deployment_id and version_id keys. Update the expected map to match. Co-authored-by: Isaac
|
|
||
| type PublicTokenInfo struct { | ||
| // Output only. The autoscope state of this token. | ||
| AutoscopeState types.Object `tfsdk:"autoscope_state"` |
There was a problem hiding this comment.
This generated field has the wrong TF value type. The SDK field is iam.AutoscopeState, a string enum, and Type() below advertises autoscope_state as types.StringType, but the struct field here is types.Object (and the legacy model has it as types.List). converters.GoSdkToTfSdkStruct therefore converts a non-empty AutoscopeState to types.StringValue(...) and then panics when setting this field: reflect.Set: value of type basetypes.StringValue is not assignable to type basetypes.ObjectValue.
Please generate this as types.String in both PublicTokenInfo and TokenInfo (and the _SdkV2 legacy variants), or suppress the field until the generator maps the enum correctly. I verified this with a local conversion probe against SDK v0.140.0.
There was a problem hiding this comment.
Thanks Simon — diagnosis is right. The root cause is upstream in the codegen: GetTfSdkFieldType has a stray clause that maps cross-package enums to types.Object/types.List, while BaseAttrType correctly maps every enum to types.StringType. The two disagree exactly when a TFSDK field is an enum imported from another proto package.
Scope here is just this one field — AutoscopeState (×4: PublicTokenInfo, TokenInfo, and their _SdkV2 variants in settings_tf). A per-struct accurate scan across all 70 internal/service/*_tf/*.go files reports zero other Object/List-vs-StringType mismatches on origin/main or on this PR's HEAD.
Nothing exercises the broken types today — grep -rn 'PublicTokenInfo\|TokenInfo' internal/providers/pluginfw/ returns zero. The panic is latent.
Codegen fix is in flight upstream; once it lands and a regen sweep follows, the four lines flip to types.String and the disagreement is gone. Proposing we merge this PR as-is (CI green) and let the regen sweep clean up the four lines in a follow-up. Let me know if you'd rather block instead.
|
If integration tests don't run automatically, an authorized user can run them manually by following the instructions below: Trigger: Inputs:
Checks will be approved automatically on success. |
This PR updates the SDK to the latest API changes.
2 new optional fields added to pipeline deployment in databricks/databricks-sdk-go#1705 which lead to assertions on test failing. Fixed the tests.
NO_CHANGELOG=true