-
Notifications
You must be signed in to change notification settings - Fork 9.9k
Add ability to create a hash of the state_store block #37278
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
base: main
Are you sure you want to change the base?
Conversation
…h of a state_store block
…ude the provider block
…blocks, and validate incoming schema and config
// The value `b.Config` will include data about the provider block nested inside state_store | ||
// so we need to ignore it. PartialDecode allows that 'extra' provider block to be ignored, | ||
// but we need to check that's the only thing being ignored. | ||
val, decodeDiags := hcldec.Decode(b.Config, spec, nil) | ||
if decodeDiags.HasErrors() { | ||
for _, diag := range decodeDiags { | ||
if diag.Detail == "Blocks of type \"provider\" are not expected here." { | ||
// We want to tolerate this. | ||
continue | ||
} | ||
diags = diags.Append(diag) | ||
} | ||
if diags.HasErrors() { | ||
return 0, diags | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@radeksimko an alternative to this could be to update the decodeStateStoreBlock logic to split out the provider and state_store config, instead of combining it all inside the single Config field. Maybe instead there could be a StateStoreConfig
, ProviderConfig
, and rawConfig
field in that struct so that the separate config can be accessed, but there's also a record of the original value?
Adds a Hash method, similar to the existing (*Backend) Hash method.
This method should be able to tolerate the nested provider block, assuming that the schema is correct. The new test added here attempts to assert that.
Target Release
1.13.x
Rollback Plan
Changes to Security Controls
Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.
CHANGELOG entry