Re: Persistent failures of test050

[Ondřej Kuzník <ondra@mistotebe.net>]

On Tue, Jun 25, 2019 at 04:45:30PM -0700, Quanah Gibson-Mount wrote:
> --On Saturday, June 22, 2019 2:06 PM -0700 Quanah Gibson-Mount
> <quanah@symas.com> wrote:
> 
>> [build@freebsd12 ~/git/openldap-2-4/tests/testrun]$ diff -u server1.out
>> server3.out
>> --- server1.out 2019-06-22 18:23:54.933600000 +0000
>> +++ server3.out 2019-06-22 18:23:55.049209000 +0000
>> @@ -1,3 +1,8 @@
>> +dn: cn=Add-Mod-Del,dc=example,dc=com
>> +cn: Add-Mod-Del
>> +objectClass: organizationalRole
>> +description: guinea pig
>> +
> 
> There appears to be two separate problems happening in test050.

Just seen another issue when the wait times are further reduced so as to
have the syncrepl establishment overlap with write traffic.

1. Servers start up and traffic starts coming in towards MMR node 1
2. syncrepl session from node 2 with node 1 as the producer is
   established
3. Add/mod/del cycles run on node 1 and are replicated towards node 2
4. Node 1 starts to run a syncrepl session towards node 2 (somehow the
   sid=001 cookie sent is older than the newest modification at the
   time, but that wouldn't really change things)
5. That triggers a present phase and the add is propagated - this then
   bypasses the sid source checks at the provider and csn checks on the
   consumer and the entry is actually added
6. The next add/mod/del cycle starts before the deletion is processed so
   add fails with LDAP_ALREADY_EXISTS and aborts the test.

It's probably the consumer CSN checks that need to be run again if we
don't receive the CSN with the PDU (which is what happens in present
phase), but that might have to be a '>=' on the contextCSN set rather
than a strict '>'? Something tells me that we need to deal with present
phase coming in with several entries with the same CSN.

Regards,

-- 
Ondřej Kuzník
Senior Software Engineer
Symas Corporation                       http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP