-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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(assertions): stack overflow while parsing template #26767
Conversation
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.
The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request
. Additionally, if clarification is needed add Clarification Request
to a comment.
exemption request please 🙂 |
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.
Hi @Chriscbr :) Can you provide a bit more in the PR description explaining how this is the root cause for the stack overflow issue?
@@ -1345,6 +1345,29 @@ describe('Template', () => { | |||
}).toThrow(/dependency cycle/); | |||
}); | |||
|
|||
test('throws when given a more complex template with cyclic dependencies', () => { |
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.
While i can see how the change in cyclic.ts
makes the recurse
function more efficient, this test isn't going to show that one way or another right? the test will succeed with the old code as well?
I'm prepared to just approve as is anyway, because this looks low risk and is hard to test, but want to make sure i have the whole picture first.
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.
I initially ran the test with the old code (unchanged) and it fails for me because of a stackoverflow error.
I think the call stack in the test case I added ends up looking like this (without the fix applied):
findCycle(deps)
recurse("Res1", ["Res1"])
recurse("Res2", ["Res1", "Res2"])
recurse("Res3", ["Res1", "Res2", "Res3"])
recurse("Res2", ["Res1", "Res2", "Res3", "Res2"])
recurse("Res3", ["Res1", "Res2", "Res3", "Res2", "Res3"])
...
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.
Ah i see
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
@kaizencc I updated the description 🙏 |
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.
Thanks @Chriscbr
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Closes #26766
The function
findCycle
tries to find a cycle by using a depth-first search (DFS). The DFS is implemented recursively in the recurse function. For each node, it tries to find a path that eventually leads back to the start of the path. If such a path is found, a cycle exists, and the nodes forming this cycle are returned.One of the bugs in the current implementation is that it only checks whether the current dependency
dep
is equal to the first node of the current pathpath[0]
. This means it will only detect a cycle if the cycle includes the first node of the search, which might not always be the case.To fix this, the function should check whether the current dependency
dep
is already somewhere in the current pathpath
. If it is, then a cycle has been found.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license