-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
cycle-safe root_stale_causes #19298
cycle-safe root_stale_causes #19298
Conversation
Current dependencies on/for this PR:
This stack of pull requests is managed by Graphite. |
else: | ||
for child in cause.children: | ||
yield from self._gather_leaves(child, level=level + 1) | ||
candidates = self._get_stale_causes(key=key) |
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.
an alternative path that i couldn't quite reason through would be to prevent the cycles from being created in this StaleCause
"tree"
for child in cause.children: | ||
yield from self._gather_leaves(child, level=level + 1) | ||
candidates = self._get_stale_causes(key=key) | ||
visited: Set[str] = set() |
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.
cant hash StaleCause
that have children
making the children
list a tuple instead just leads to hash
entering the same recursion nightmare
root_causes.append(cause) | ||
else: | ||
next_candidates.extend(cause.children) | ||
visited.add(cause.sort_key) # maybe replace with better key |
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.
Somewhat surprised that using this sort_key as the unique identifier here isn't causing any problems -- I'd expect there to be cases where there are duplicates here (i.e. a parent's code version AND data version have both updated), and in that case it looks like this code would only capture one of those. easy fix would just be to use a tuple that contains the reason/cause category properties in there as well I think, but maybe I'm missing something
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.
Ya thats what my comment was getting at. I was curious if I would get any test failures. Can definitely replace the key set up like you are suggesting.
c000343
to
c6cf6f2
Compare
c6cf6f2
to
818e22a
Compare
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.
Hard to imagine this making things worse, although it's still a bit of a mystery as to why this is being hit in the first place
similar to #18516, update the root cause calculation to be safe in the event a cycle happens ## How I Tested These Changes was able to verify the fix against a complex standing deployment, have not been able to distill to minimal repro
similar to #18516, update the root cause calculation to be safe in the event a cycle happens ## How I Tested These Changes was able to verify the fix against a complex standing deployment, have not been able to distill to minimal repro
similar to #18516, update the root cause calculation to be safe in the event a cycle happens
How I Tested These Changes
was able to verify the fix against a complex standing deployment, have not been able to distill to minimal repro