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.

Sign up for GitHub

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

Jump to bottom

Seemingly random parse failures #4982

Closed
lukesteensen opened this issue Feb 3, 2016 · 4 comments · Fixed by #5026
Closed

Seemingly random parse failures #4982

lukesteensen opened this issue Feb 3, 2016 · 4 comments · Fixed by #5026
Labels
bug core

Comments

@lukesteensen
Copy link

This can be reproduced on v0.6.11 with https://gist.github.com/lukesteensen/00d59e66f3ac20b4b6e8

It's pretty trivial to run the example multiple times and see failures while refreshing state, creating the plan, and applying the plan.

We've run into cases in our actual infrastructure where instances were destroyed and not recreated due to this error happening mid-apply.
@phinze
Copy link
Contributor

phinze commented Feb 4, 2016

Thanks for the report @lukesteensen. Sounds like a race condition in the parser. Sorry for the trouble it caused you during apply - we'll get this looked at ASAP!

@lukesteensen
Copy link
Author

Thanks @phinze! Much appreciated

@phinze
Copy link
Contributor

phinze commented Feb 4, 2016

Just a quick update here - I've got local reproduction thanks to your example. Still working on root cause diagnosis. Will follow up as soon as I know more.

phinze added a commit that referenced this issue Feb 5, 2016
@phinze
core: Make copies when creating destroy nodes
7dcdf37 
Fixes an interpolation race that was occurring when a tainted destroy
node and a primary destroy node both tried to interpolate a computed
count in their config. Since they were sharing a pointer to the _same_
config, depending on how the race played out one of them could catch the
config uninterpolated and would then throw a syntax error.

The `Copy()` tree implemented for this fix can probably be used
elsewhere - basically we should copy the config whenever we drop nodes
into the graph - but for now I'm just applying it to the place that
fixes this bug.

Fixes #4982
@phinze phinze mentioned this issue Feb 5, 2016
Merged
phinze added a commit that referenced this issue Feb 5, 2016
@phinze
core: Make copies when creating destroy nodes
d927f66 
Fixes an interpolation race that was occurring when a tainted destroy
node and a primary destroy node both tried to interpolate a computed
count in their config. Since they were sharing a pointer to the _same_
config, depending on how the race played out one of them could catch the
config uninterpolated and would then throw a syntax error.

The `Copy()` tree implemented for this fix can probably be used
elsewhere - basically we should copy the config whenever we drop nodes
into the graph - but for now I'm just applying it to the place that
fixes this bug.

Fixes #4982 - Includes a test covering that race condition.
phinze added a commit that referenced this issue Feb 9, 2016
@phinze
core: Make copies when creating destroy nodes
3f72837 
Fixes an interpolation race that was occurring when a tainted destroy
node and a primary destroy node both tried to interpolate a computed
count in their config. Since they were sharing a pointer to the _same_
config, depending on how the race played out one of them could catch the
config uninterpolated and would then throw a syntax error.

The `Copy()` tree implemented for this fix can probably be used
elsewhere - basically we should copy the config whenever we drop nodes
into the graph - but for now I'm just applying it to the place that
fixes this bug.

Fixes #4982 - Includes a test covering that race condition.
joshmyers pushed a commit to joshmyers/terraform that referenced this issue Feb 18, 2016
@phinze @joshmyers
core: Make copies when creating destroy nodes
0939979 
Fixes an interpolation race that was occurring when a tainted destroy
node and a primary destroy node both tried to interpolate a computed
count in their config. Since they were sharing a pointer to the _same_
config, depending on how the race played out one of them could catch the
config uninterpolated and would then throw a syntax error.

The `Copy()` tree implemented for this fix can probably be used
elsewhere - basically we should copy the config whenever we drop nodes
into the graph - but for now I'm just applying it to the place that
fixes this bug.

Fixes hashicorp#4982 - Includes a test covering that race condition.
bigkraig pushed a commit to bigkraig/terraform that referenced this issue Mar 1, 2016
@phinze @bigkraig
core: Make copies when creating destroy nodes
014ed61 
Fixes an interpolation race that was occurring when a tainted destroy
node and a primary destroy node both tried to interpolate a computed
count in their config. Since they were sharing a pointer to the _same_
config, depending on how the race played out one of them could catch the
config uninterpolated and would then throw a syntax error.

The `Copy()` tree implemented for this fix can probably be used
elsewhere - basically we should copy the config whenever we drop nodes
into the graph - but for now I'm just applying it to the place that
fixes this bug.

Fixes hashicorp#4982 - Includes a test covering that race condition.
@ghost
Copy link

ghost commented Apr 28, 2020

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 Apr 28, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
bug core
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

core: Make copies when creating destroy nodes hashicorp/terraform
2 participants
@phinze @lukesteensen