Comment 10 for bug 1607814

Rabi, to me it looks like a different issue, and I think we should fine another ticket.

I think that when a resource or a nested stack updates it-self, like a auto-scaling group, it doesn't check for a new traversal of parent stack. It is possible that the nested stack is being updated and at the same time the new traversal (update or delete) is running and it failed to grab the lock, and then assumed that the locked resource would re-trigger after unlocking. The solution that comes to my mind immediately is that the update should check if it was part of new traversal or not. If the nested stack update is part of new traversal then it shouldn't to anything, but if the update is a self update triggered by other event, then it should try to re-trigger by looking at sync point.