-
Notifications
You must be signed in to change notification settings - Fork 504
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
Fix infinite loop on variable resolution #393
Fix infinite loop on variable resolution #393
Conversation
Codecov Report
@@ Coverage Diff @@
## master #393 +/- ##
==========================================
- Coverage 63.55% 63.35% -0.20%
==========================================
Files 85 85
Lines 1904 1910 +6
==========================================
Hits 1210 1210
- Misses 591 595 +4
- Partials 103 105 +2
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your contribution.
This fix breaks the infinite loop, but does not completely fix the problem of resolving variables initialized in the Parent module.
We may need to think of a way to resolve variables referenced in the Parent Module call as well.
@kanchwala-yusuf maybe you could explain a little more on this?
The function I am patching is called |
@kanchwala-yusuf - I applied the same fix in |
@@ -87,6 +87,10 @@ func (r *RefResolver) ResolveVarRef(varRef string) interface{} { | |||
if reflect.TypeOf(val).Kind() == reflect.String { | |||
valStr := val.(string) | |||
resolvedVal := strings.Replace(varRef, varExpr, valStr, 1) | |||
if varRef == resolvedVal { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dinedal we do not require the change here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Come to think of it, this may not hurt us at all.
Sorry for the typo there. I meant "We may need to think of a way to resolve variables referenced in the Parent Module call as well." I have also edited my previous comment. |
Hey @dinedal, Let me elaborate more on how we resolve variables. Variable values initialized in the parent module call take precedence over values initialized in the same module, hence we execute the following steps:
Now, issue is the parent module call itself references to another variable. That's why terrascan is stuck in the infinite loop. Your fix breaks the loop but, does not resolve variables in the parent module call. We need to do figure out a way to do that. |
@kanchwala-yusuf OK, I don't understand, let me tell you my understanding and maybe you can help point out what I'm not seeing.
I guess my confusion arrives in two places:
|
c89bb6f
to
d356d5c
Compare
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
@kanchwala-yusuf Thanks for the merge! |
When executing on a terraform HCL IaC, it is possible for a variable to end up resolving to itself because it is undefined at the time of analysis (defined in tfvars or on the command line)
This logic detects when a variable resolves to itself and breaks out of the infinite loop that would be created.
fixes #406