Rudder

In Rudder, we have a cache with all interesting node information.

That cache is based on "modifyTimeStamp" attribute value from the LDAP directory. That value is precise to the second.

But it can happen that there is several modification in the same second, and that we are looking for a cache update just at that moment. When that happen, all modification after the cache check and until a new modification is done are lost, because the cache thinks it is up-to-date, and he don't check for more.

Ex:

12:00:00.123 - modification on node 1 (modifyTimestamp = 12:00:00 12:00:00.000)
12:00:00.435 - get node information for cache (last modification noted at: 12:00:00)
12:00:00.123 - modification on node 2 (modifyTimestamp = 12:00:00 12:00:00.000)

Then, on next cache up-to-date check, we look if there is modification since 12:00:01 (actually, since 12:00:00.001). There is none registered => no cache update.

This seems to be the cause of strange bugs like #12474 (not sure).