fix: Include backend in dependent bodies to avoid false negatives #251
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.
Context
A bug was discovered as part of testing hashicorp/terraform-ls#1368 - see below.
The assumption I made in the beginning of investigating this bug - which is likely the same assumption made while the bug was introduced in the first place - that the
backend
attribute is part of a core schema which we'd end up keeping after merge, just like we keepdepends_on
and similar ones.However, the
terraform_remote_state
data source is a bit different in that the "merge hierarchy" is much flatter, where the "non-backend" body is on the same level as the "backend-specific" body, so no merging can ever happen between the two:Implementation Notes
I initially thought we could just set the
backend
Constraint to the givenschema.LiteralValue{}
for each backend. While this would address the validation problem, it would also make it much more difficult to solve hashicorp/terraform-ls#1284 as we wouldn't have access to all the other backends and their details at completion time, when the merging has already taken place (becausebackend
has matching value).