Howard Chu wrote:
In at least one case I'm seeing a valid update being rejected because the incoming cookie seems to have been confused with another one. This happens when a NEW_COOKIE message is received. I'll note that sending NEW_COOKIE messages is a recent change (ITS#5972), and there is no valid case for them to be occurring in test050. I.e., NEW_COOKIE should be sent in a partial replication situation, where an entry changed in the naming context but it's not within the consumer's scope of interest. In test050, the consumer's scope of interest is the entire naming context. So this at least gives me one area to look for a fix.
This piece of the ITS#5972 patch is part of the problem --- syncprov.c 5 Mar 2009 16:53:01 -0000 1.266 +++ syncprov.c 12 Mar 2009 08:42:54 -0000 @@ -1245,7 +1245,7 @@ } else if ( !saveit && found ) { /* send DELETE */ syncprov_qresp( opc, ss, LDAP_SYNC_DELETE ); - } else if ( !saveit ) { + } else if ( !saveit && !fc.fscope ) { syncprov_qresp( opc, ss, LDAP_SYNC_NEW_COOKIE ); } if ( !saveit && found ) {
My diff above is also not the correct fix, which is why I haven't committed it yet.
The current operation may not have been caught by the previous if conditions for 3 reasons: 1) the change is out of the consumer's scope 2) the change doesn't match the consumer's filter 3) the change is older than the consumer's cookie
The NEW_COOKIE message must only be sent for conditions 1 and 2, but it's currently also being sent for 3. Since the cookie comparison is tacked onto the consumer's filter, an additional comparison is needed to weed this out. (Normally 3 can't be true, but this is MMR where the consumer might have already received this change from some other provider.)
I haven't looked yet, but I suspect there is a corresponding bug in the consumer where it acts on a NEW_COOKIE message whether it's valid or not.
I'm also inclined to back out #5972 and its related patches (#5973, #6001) for this release. We were looking for bug fixes and stability, and they've been quite destabilizing.