12 Commits (00a76d019a3e5b4d9d040a3e28c9e0b4e56ad951)

Author	SHA1	Message	Date
Brian Flad	a8e3787afc	helper/schema: Prevent setSet() panic with typed nil ... References: * https://github.com/hashicorp/terraform/issues/14418 * v0.9.5 (original bug report): a59ee0b30e/helper/schema/field_writer_map.go (L311) * v0.11.12 (Terraform AWS Provider discovery): 057286e522/helper/schema/field_writer_map.go (L343) When creating flatten functions in Terraform Providers that return *schema.Set, its possible to return a typed `nil`, e.g. ```go func flattenHeaders(h *cloudfront.Headers) *schema.Set { if h.Items != nil { return schema.NewSet(schema.HashString, flattenStringList(h.Items)) } return nil } ``` This previously could cause a panic, e.g. ``` panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x1881911] goroutine 1325 [running]: github.com/hashicorp/terraform/helper/schema.(*MapFieldWriter).setSet(0xc00054bf00, 0xc00073efa0, 0x5, 0x5, 0x5828140, 0x0, 0xc0002cea50, 0xc000e996a8, 0xc001026e40) /Users/bflad/go/pkg/mod/github.com/hashicorp/terraform@v0.11.12/helper/schema/field_writer_map.go:343 +0x211 ``` Here we catch the typed `nil` and return an empty list flatmap result instead. Unit testing result prior to code update: ``` --- FAIL: TestMapFieldWriter (0.00s) panic: runtime error: invalid memory address or nil pointer dereference [recovered] panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x1777cdc] goroutine 913 [running]: testing.tRunner.func1(0xc00045b800) /usr/local/Cellar/go/1.12.1/libexec/src/testing/testing.go:830 +0x392 panic(0x192cf20, 0x2267ca0) /usr/local/Cellar/go/1.12.1/libexec/src/runtime/panic.go:522 +0x1b5 github.com/hashicorp/terraform/helper/schema.(*MapFieldWriter).setSet(0xc0004648a0, 0xc0004408d0, 0x1, 0x1, 0x19e3de0, 0x0, 0xc00045c600, 0x30, 0x19e0080) /Users/bflad/src/github.com/hashicorp/terraform/helper/schema/field_writer_map.go:344 +0x68c github.com/hashicorp/terraform/helper/schema.(*MapFieldWriter).set(0xc0004648a0, 0xc0004408d0, 0x1, 0x1, 0x19e3de0, 0x0, 0x1, 0x18) /Users/bflad/src/github.com/hashicorp/terraform/helper/schema/field_writer_map.go:107 +0x28b github.com/hashicorp/terraform/helper/schema.(*MapFieldWriter).WriteField(0xc0004648a0, 0xc0004408d0, 0x1, 0x1, 0x19e3de0, 0x0, 0x0, 0x0) /Users/bflad/src/github.com/hashicorp/terraform/helper/schema/field_writer_map.go:89 +0x504 github.com/hashicorp/terraform/helper/schema.TestMapFieldWriter(0xc00045b800) /Users/bflad/src/github.com/hashicorp/terraform/helper/schema/field_writer_map_test.go:337 +0x2ddd testing.tRunner(0xc00045b800, 0x1a44f90) /usr/local/Cellar/go/1.12.1/libexec/src/testing/testing.go:865 +0xc0 created by testing.(*T).Run /usr/local/Cellar/go/1.12.1/libexec/src/testing/testing.go:916 +0x35a ```	7 years ago
Chris Marchesi	3fa11e456b	helper/schema: Clear existing map/set/list contents before overwriting ... There are situations where one may need to write to a set, list, or map more than once per single TF operation (apply/refresh/etc). In these cases, further writes using Set (example: d.Set("some_set", newSet)) currently create unstable results in the set writer (the name of the writer layer that holds the data set by these calls) because old keys are not being cleared out first. This bug is most visible when using sets. Example: First write to set writes elements that have been hashed at 10 and 20, and the second write writes elements that have been hashed at 30 and 40. While the set length has been correctly set at 2, since a set is basically a map (as is the entire map writer) and map results are non-deterministic, reads to this set will now deliver unstable results in a random but predictable fashion as the map results are delivered to the caller non-deterministic - sometimes you may correctly get 30 and 40, but sometimes you may get 10 and 20, or even 10 and 30, etc. This problem propagates to state which is even more damaging as unstable results are set to state where they become part of the permanent data set going forward. The problem also applies to lists and maps. This is probably more of an issue with maps as a map can contain any key/value combination and hence there is no predictable pattern where keys would be overwritten with default or zero values. This is contrary to complex lists, which has this problem as well, but since lists are deterministic and the length of a list properly gets updated during the overwrite, the problem is masked by the fact that a read will only read to the boundary of the list, skipping any bad data that may still be available due past the list boundary. This update clears the child contents of any set, list, or map before beginning a new write to address this issue. Tests are included for all three data types.	9 years ago
James Nugent	074545e536	core: Use .% instead of .# for maps in state ... The flatmapped representation of state prior to this commit encoded maps and lists (and therefore by extension, sets) with a key corresponding to the number of elements, or the unknown variable indicator under a .# key and then individual items. For example, the list ["a", "b", "c"] would have been encoded as: listname.# = 3 listname.0 = "a" listname.1 = "b" listname.2 = "c" And the map {"key1": "value1", "key2", "value2"} would have been encoded as: mapname.# = 2 mapname.key1 = "value1" mapname.key2 = "value2" Sets use the hash code as the key - for example a set with a (fictional) hashcode calculation may look like: setname.# = 2 setname.12312512 = "value1" setname.56345233 = "value2" Prior to the work done to extend the type system, this was sufficient since the internal representation of these was effectively the same. However, following the separation of maps and lists into distinct first-class types, this encoding presents a problem: given a state file, it is impossible to tell the encoding of an empty list and an empty map apart. This presents problems for the type checker during interpolation, as many interpolation functions will operate on only one of these two structures. This commit therefore changes the representation in state of maps to use a "%" as the key for the number of elements. Consequently the map above will now be encoded as: mapname.% = 2 mapname.key1 = "value1" mapname.key2 = "value2" This has the effect of an empty list (or set) now being encoded as: listname.# = 0 And an empty map now being encoded as: mapname.% = 0 Therefore we can eliminate some nasty guessing logic from the resource variable supplier for interpolation, at the cost of having to migrate state up front (to follow in a subsequent commit). In order to reduce the number of potential situations in which resources would be "forced new", we continue to accept "#" as the count key when reading maps via helper/schema. There is no situation under which we can allow "#" as an actual map key in any case, as it would not be distinguishable from a list or set in state.	10 years ago
Paul Hinze	edaf5795a5	Merge pull request #3257 from fatih/fix-nil-setting-schema ... schema: delete non existing values	11 years ago
Panagiotis Moustafellos	e4845f75cc	removed extra parentheses	11 years ago
Fatih Arslan	f269d4fc8c	schema: add test for nil string case	11 years ago
Mitchell Hashimoto	9b8b38cbb1	helper/schema: test that set can be nil	11 years ago
Mitchell Hashimoto	e4f0f6b15d	helper/schema: more tests	11 years ago
Mitchell Hashimoto	e32cd396ad	helper/schema: add test for GH-814	11 years ago
Mitchell Hashimoto	448887f3c4	helper/schema: map counts in state	11 years ago
Mitchell Hashimoto	f64b09a045	helper/schema: more tests	11 years ago
Mitchell Hashimoto	03c6453a72	helper/schema: FieldWriter, replace Set	11 years ago