The orchestration process injects itself into the AR lifecycle. During an update the host object's attributes are modified, a copy is then taken and then the callbacks use self and self.old for further processing
However if an association has already been accessed then AR caches this in the object and that can mean that later references to self.operatingsystem refer to the cached value. I.E. the value before the host's attributes were changed.
The same is true for the old object. To avoid this, the setup_clone operation should ensure that any attribute that was changed and that is an association_id, be used to reload the AR association.
Ohad,
can you think of any possible side effects? I am also unclear as to how this could have gone undetected for so long.
It is easy to see this occur. Just change a host's operatingsystem and breakpoint in setup_clone. You will see that self.operatingsystem does not match Operatingsystem.find @attributes["operatingsystem_id"]