-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Work around a potentially bad assert in the engine #1644
Conversation
The engine asserts if presented with a plan that deletes the same URN more than once. This has been empirically proven to be possible, so I am removing the assert.
// | ||
// Regardless, it is better to admit strange behavior in corner cases than it is to crash the CLI | ||
// whenever we see multiple deletes for the same URN. | ||
// contract.Assert(!sg.deletes[res.URN]) |
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.
Would it be worthwhile to glog (maybe at V(7) like the above) in this case?
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.
Yep, will do.
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.
LGTM aside from @ellismg's comment
) | ||
|
||
// Test that the engine tolerates two deletions of the same URN in the same plan. | ||
func TestDoublePendingDelete(t *testing.T) { |
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 for the new tests here!
Thanks for the reviews - I'm going to go ahead and merge this if there aren't any objections. |
The engine asserts if presented with a plan that deletes the same URN
more than once. This has been empirically proven to be possible, so I am
removing the assert.
This fixes the immediate badness of #1503, but I'm going to leave the issue open until we understand all of the implications of deleting the same URN multiple times. I am certain that there are bugs lurking here and we may have to re-think how we do pending deletes in order to iron them all out.
This PR makes the CLI not crash when it sees a plan that deletes the same URN multiple times, which I think is a big enough improvement to justify the risk. It is really, really annoying to fix a stack that has wandered into this state as it is today.