Bug#1010608: openldap: Flaky test test063-delta-multiprovider

[Ryan Tandy]

Control: tag -1 help

Hi Adrian,

On Thu, May 05, 2022 at 02:54:14PM +0300, Adrian Bunk wrote:
>https://tests.reproducible-builds.org/debian/rbuild/unstable/i386/openldap_2.5.11+dfsg-1.rbuild.log.gz

I'm afraid this link has been superseded by the new upload (which built 
successfully & reproducibly). Just to confirm, you're saying that it 
failed for the same reason as the amd64 build?

>Using ldapadd to populate server 2...
>Using ldapsearch to read all the entries from server 1...
>Using ldapsearch to read all the entries from server 2...
>Using ldapsearch to read all the entries from server 3...
>Using ldapsearch to read all the entries from server 4...
>Comparing retrieved entries from server 1 and server 2...
>Comparing retrieved entries from server 1 and server 3...
>test failed - server 1 and server 3 databases differ

I looked at this script, and I think I see how this part might be 
fragile: *if* I'm reading correctly, it waits for server 1 to receive 
the changes, but then I think it proceeds with the comparison 
immediately, and could fail if server 3 or 4 was slower.

https://git.openldap.org/openldap/openldap/-/blob/master/tests/scripts/test063-delta-multiprovider#L309-359

This is also different from the previous section (lines 264-294) which 
waits a flat $SLEEP1 seconds (default: 7) for changes to be synced.

However I'm not comfortable proposing changes to the script if I can't 
validate them. I could really use some help figuring out how to 
reproduce this failure. I would need to have just server 3 or 4 affected 
by some slowdown - and not sure what kind, whether CPU or network or 
disk. I guess I'll start by seeing if I can use tc to add latency to 
just the specific port...

thanks,
Ryan