Skip to content
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

prevent an empty string from being lost #21806

Merged
merged 1 commit into from
Jun 25, 2019
Merged

Conversation

jbardin
Copy link
Member

@jbardin jbardin commented Jun 19, 2019

The helper/schema diff process loses empty strings, causing them to show
up as unset (null) during apply. Besides failing to show as set by
GetOk, the absence of the value also triggers the schema to insert a
default value again during apply.

It would also be be preferable if the defaults weren't re-evaluated
again during ApplyResourceChange, but that would require a more invasive
patch to the field readers, and ensuring the empty string is stored in
the plan should block the default.

Fixes #21760

@jbardin jbardin requested a review from a team June 19, 2019 21:20
Copy link
Contributor

@apparentlymart apparentlymart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like I've lost enough context in the intervening weeks to not be able to fully reason about what this is gonna do, but I trust that you have more context loaded and have thought this through, and so my review here focused on "does this code look like it does what it was intending to do". 😀

The helper/schema diff process loses empty strings, causing them to show
up as unset (null) during apply. Besides failing to show as set by
GetOk, the absence of the value also triggers the schema to insert a
default value again during apply.

It would also be be preferable if the defaults weren't re-evaluated
again during ApplyResourceChange, but that would require a more invasive
patch to the field readers, and ensuring the empty string is stored in
the plan should block the default.
@jbardin jbardin force-pushed the jbardin/lost-empty-strings branch from 0b23912 to 4dcda04 Compare June 19, 2019 21:42
@jbardin
Copy link
Member Author

jbardin commented Jun 19, 2019

Forgot the unit test for that change.
The behavioral change is quite small, a plan cannot replace an empty string with null, where this used to only be enforced for apply. This also further limits the check to empty strings, since that is the ambiguous flatmap case.

@jbardin jbardin merged commit f362198 into master Jun 25, 2019
@jbardin jbardin deleted the jbardin/lost-empty-strings branch June 25, 2019 16:32
@ghost
Copy link

ghost commented Jul 26, 2019

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators Jul 26, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Default value are applied for empty string when there's no existing state.
2 participants