59 Commits (add-missing-variable-loading)

Author	SHA1	Message	Date
Radek Simko	0fe906fa8c	make copyrightfix	2 months ago
Liam Cervante	2a1b4c3ed4	Update go-cty and HCL for 1.13 release (#37298)	9 months ago
James Bardin	64c983275e	skip set elem comparison when already matched ... If both elements of the set have already been matched, there is no need to compare them again.	10 months ago
James Bardin	368b55f57d	fix nested structured data resource plan ... Another case where we missed an unknown check for data resource planning	1 year ago
James Bardin	56137f3b6c	prior may be unknown when planning data sources ... While the proposed plan value for managed resource is only a suggestion, deferred data sources must be completely planed by core, hence set appropriate unknown values. We do this by using a prior unknown, which must be taken into account by all nested types.	1 year ago
Radek Simko	289a3568da	Address `go vet` 1.24 failures (#36485) ... * address go vet failures * avoid unnecessary .Error()	1 year ago
Daniel Schmidt	970ff7f6ec	ephemeral: providers are responsible for setting write-only attributes to null	1 year ago
Liam Cervante	50233d7a78	stacks: support sensitive input values in planned changes (#35640) ... * stacks: support sensitive input values in planned changes * stacks: Fix panic when applying sensitive inputs The stacks-specific check that a given plan's input variable values remain unchanged at apply time would previously panic when given a marked value. Marks are not important for this check, so we simply remove them to ensure that it passes. This seems in line with how AssertObjectCompatible works, which I'm taking as precedent. The new test added in this commit panics without the corresponding code change. --------- Co-authored-by: Alisdair McDiarmid <alisdair@users.noreply.github.com>	2 years ago
Liam Cervante	46393f2a92	stacks: apply automatic type conversion before comparing inputs (#35530) ... * stacks: apply automatic type conversion before comparing inputs * correct error message for missing ephemeral value during apply	2 years ago
James Bardin	2562420d16	prevent panics with null objects in nested attrs ... When descending into nested structural attributes, don't try to extract attributes from null objects. Unlike with blocks, nested attributes allow the possibility of assigning null values. While these technically aren't allowed to be altered, we need to accept these for compatibility.	2 years ago
Martin Atkins	d86eee6c1f	go.mod: Eliminate github.com/apparentlymart/go-dump ... I originally wrote this library as a stopgap measure because davecgh/go-spew produced a hard-to-read representation of cty.Value due to exposing the raw internals, whereas my "go-dump" instead just pretty-prints whatever fmt.Sprintf("%#v", ...) would return for a given value. However, in the meantime I wrote ctydebug as a more cty-specialized library for this purpose, and we switched to using go-cmp as our primary library for deep-comparing data structures, and so our few remaining uses of apparentlymart/go-dump were vestigial in tests that haven't been updated recently enough to have been updated to our new standards. This commit therefore swaps out all use of that library with combinations of go-cmp and ctydebug, matching our current standards for how to do these sorts of things in tests. This removes our dependency on "go-dump" altogether. At least one of our dependencies is still using go-dump as part of its own test suite, and so the Go toolchain still includes its declared version in our go.sum file. However, this library is no longer linked in to Terraform either in real builds or in test binaries, and so it gets dropped entirely from our go.mod file.	2 years ago
hashicorp-copywrite[bot]	53c34ff49c	Update copyright file headers to BUSL-1.1	3 years ago
Martin Atkins	d49e991c3c	plans/objchange: Support nested unknowns in our unrefinedValue shim ... Several parts of the objchange logic incorrectly use cty.Value.RawEquals for value comparison, instead of more appropriate comparison methods like cty.Value.Equals or c.Value.Range().Includes. That makes them incorrectly consider two unknown values with the same type but different refinements as always non-equal, rather than evaluating based on the overlap between the refinements (if any). As a short-term fix for that we previously added this unrefinedValue shim that just strips away the refinements for comparison, thus allowing callers to continue using RawEquals as long as they've already taken care of all of the other things that can make that go wrong, such as value marks. Unfortunately the shim was too simplistic and only supported direct unknown values. Unknown values with refinements can also appear nested inside known container values such as collections, so the shim needs to recursively un-refine the entire data structure in that case. This is still intended only as a temporary fix until we have time to revisit all of the callers and make them use cty's own logic for comparison. Using cty's own logic will make the results more precise, because e.g. it can notice if two unknown strings have different known prefixes and therefore cannot possibly be equal despite not being fully known. For now this shim will accept any pair of unknown values of the same type as equal, regardless of refinement.	3 years ago
James Bardin	f6c536e436	validate planned set sizes using refinements	3 years ago
James Bardin	3c8a163583	set length is unknown with partially known elems ... If a set contains partially known values the length is unknown which causes assertPlannedObjectValid to fail valid plans. Revert to the old method if using LengthInt for the set lengths, which returns the maximum number of possible elements, with a guard for entirely unknown set values.	3 years ago
Martin Atkins	4c439b099f	plans/objchange: Don't consider refinements when validating plans ... Providers that existed prior to refinements (all of them, at the time of writing) cannot preserve refinements sent in unknown values in the configuration, and even if one day providers _are_ aware of refinements there we might add new ones that existing providers don't know how to handle. For that reason we'll absolve providers of the responsibility of preserving refinements from config into plan by fixing some cases where we were incorrectly using RawEquals to compare values; that function isn't appropriate for comparing values that might be unknown. However, to avoid a disruptive change right now this initial fix just strips off the refinements before comparing. Ideally this should be using Value.Equals and handling unknown values more explicitly, but we'll save that for a possible later improvement. This does not include a similar exception for validating whether a final value conforms to a plan because the plan value and the final value are both produced by the same provider and so providers ought to be able to be consistent with their _own_ treatment of refinements, if any. Configuration is special because Terraform itself generates that, and so it can potentially contain refinements that a particular provider has no awareness of.	3 years ago
Martin Atkins	dfe5e1ddc4	plans/objchange: Providers must honor their unknown value refinements ... If the original value was unknown but its range was refined then the provider must return a value that is within the refined range, because otherwise downstream planning decisions could be invalidated. This relies on cty's definition of whether a value is in a refined range, which has pretty good coverage for the "false" case and so should give a pretty good signal, but it'll probably improve over time and so providers must not rely on any loopholes in the current implementation and must keep their promises even if Terraform can't currently check them.	3 years ago
James Bardin	2f308cf948	Merge pull request #32962 from hashicorp/jbardin/validate-unknown-coll-attrs ... validate unknown nested attribute collections	3 years ago
hashicorp-copywrite[bot]	325d18262e	[COMPLIANCE] Add Copyright and License Headers	3 years ago
James Bardin	8ab7af8c5f	validate unknown nested attribute collections ... It is not valid for a provider to return an unknown value for a configured nested collection, but we need to check for unknowns before comparing the number of values in the collection.	3 years ago
kmoe	76b34e891c	remove unused actionforchange (#32759)	3 years ago
James Bardin	b6906f3572	Merge pull request #32563 from hashicorp/jbardin/optional-computed-comparison-next ... a new method of `ProposedNew` set comparison	3 years ago
James Bardin	799f4a76ab	Merge pull request #32554 from hashicorp/jbardin/optional-computed-comparison ... refactor ProposedNew	3 years ago
James Bardin	33c1ffa7c2	Merge pull request #32553 from hashicorp/jbardin/nesting-map-objchange ... Fix crashes with NestingMap values	3 years ago
James Bardin	d1d55653e4	update comment for fixed test	3 years ago
James Bardin	60d6e52021	a new method of ProposedNew set comparison ... The existing set comparison method uses the prior elements with the computed portions nulled out to find candidates to match the configuration. This has the shortcoming of always removing optional+computed attributes, because we have not yet found the configuration to know if attribute was set or not. Rather than having to take the most pessimistic value before comparison to precompute the nulled values, we can compare each candidate directly, walking the values in tandem. Each prior value is compared against the config and checked to see if it could have been derived from that configuration value, which allows us to treat optional+computed as optional if there is config and computed if there is not. This removes the ambiguity from having optional+computed attributes within sets, giving us consistent plans when all values are known. Unknown values of course are still undecidable, as are edge cases were providers refresh with altered values or retained changed prior values plan that were deemed not functionally significant.	3 years ago
James Bardin	9459f0b214	refactor ProposedNew ... Unify the ProposedNew paths for Blocks and Objects. Break out the individual case blocks into functions, then use a common interface to dispatch the object creation to the correct function based on schema type. This cuts the code in half, and prevents the block and object behavior from diverging.	3 years ago
James Bardin	375c2da3e3	update NestingMap logic ... Simplify the logic in the NestingMap cases. Prevent uninitialized cty.NilVal from appearing in block case.	3 years ago
James Bardin	fcbfc365e6	fix panics when handling null values in maps ... NestingMap structures are not well tested, and we panic in many situations when null crops up. Fix the first test cases and start refactoring best we can. This probably won't go so far as making all the objchange functions generic over Block and Object, but we can simplify a lot and verify parity in implementations for now.	3 years ago
James Bardin	8e917e5513	check for non-computed within optional+computed ... We can check if an object in state must have at least partially come from configuration, by seeing if the prior value has any non-null attributes which are not computed in the schema. This is used when the configuration contains a null optional+computed value, and we want to know if we should plan to send the null value or the prior state.	3 years ago
James Bardin	e16b848d00	expand test case	3 years ago
James Bardin	7ca9abe463	optional+computed ... Simplify the proposedNewAttributes cases, and add another test for coverage.	3 years ago
James Bardin	470ed22730	failing tests for nested sets in objchange ... Add a number of test cases which fail without the prior changes.	3 years ago
James Bardin	048ee3432c	better handling of nested sets in objchange ... Combine and simplify the set comparison functions for NestingSet blocks and attribute types. The set handling for structural attributes was not recursing into nested values. Once a simplified method for comparing set elements was devised for nested types, it turns out the same method could be applied to nested set blocks as well.	3 years ago
James Bardin	ac4f5fe2f9	reformat	3 years ago
James Bardin	986127e619	remove unused isConfig arg	3 years ago
James Bardin	e661e91bff	failing test for nested set types	3 years ago
James Bardin	93f739e927	optional+computed can contain nested objects ... When structural attributes were added, optional+computed were not correctly handled when containing nested values which could themselves be computed. This would cause terraform to ignore previously computed values from state when generating the proposed plan. The special case for optional+computed was incorrect, but isn't needed in the context of planning new values anyway. Attributes are either computed, or not computed. When optional+computed is set and there is no configuration, the attribute is treated as computed. It is up to the provider to determine how and when to deal with any changes to that computed value.	3 years ago
James Bardin	0a73e216e5	Merge pull request #32463 from hashicorp/jbardin/nesting-single-null ... NestingSingle blocks can be null	3 years ago
Liam Cervante	38afb41787	Structured plan renderer: Introduce support for multiline and JSON strings (#32488) ... * pause implementation * change -> diff, value -> change * add support for json and multiline strings to the primitive renderer * goimports * remove unused function * go fmt * address comments	3 years ago
James Bardin	d5d6d61c4c	NestingSingle blocks can be null ... NestingSingle blocks removed from from the config were causing a plan to error out with "... planned for existence but config wants absence". Terraform core was proposing an incorrect value in this case, taking the prior instead as a fallback because a null value was not expected. Unlike other collection nesting modes, a NestingSingle block not present in the configuration is a null value, and should be allowed when planning a new value rather than building an empty object or falling back to the prior value.	3 years ago
James Bardin	ea193d5ce6	don't panic with a null list block value in config ... Using ignore_changes with a list block, where the provider returned an invalid null value for that block, can result in a panic when validating the plan. Future releases may prevent providers from storing a null block in state, however we can avoid the panic for now. Only the NestingList case needs to be handled, because legacy providers only have list and set blocks, and the set case does not use the config value.	3 years ago
James Bardin	fd76846d35	two more locations where Attribute.Type was used	4 years ago
James Bardin	a6a08fe84a	AssertPlanValid for computed with config value ... Return early from AssertPlanValid for any attribute which is only computed. We currently fail if there's a config value, but that could only happen because of core, not because of the provider.	4 years ago
James Bardin	58d85fcc2e	add test for planing unknown data source values	5 years ago
James Bardin	18d354223e	objchange: fix ProposedNew from null objects ... The codepath for AllAttributesNull was not correct for any nested object types with collections, and should create single null values for the correct NestingMode rather than a single object with null attributes. Since there is no reason to descend into nested object types to create nullv alues, we can drop the AllAttributesNull function altogether and create null values as needed during ProposedNew. The corresponding AllBlockAttributesNull was only called internally in 1 location, and simply delegated to schema.EmptyValue. We can reduce the package surface area by dropping that function too and calling EmptyValue directly.	5 years ago
James Bardin	331dc8b14c	handle empty containers in ProposedNew NestedTypes ... Empty containers of NestedTypes were not handled in ProposedNew, causing plans to be submitted with null values where there was configuration present.	5 years ago
James Bardin	8ed9a270e5	Merge pull request #29559 from hashicorp/jbardin/optional-attrs ... Prevent `ObjectWithOptionalAttrs` from escaping	5 years ago
James Bardin	43123d284e	optional attrs should not be in ProposedNew	5 years ago
James Bardin	782132da33	remove incorrect computed check ... The config is already validated, and does not need to be checked in AssertPlanValid. Add some more coverage for plan validation.	5 years ago