Done for 2.3.1.

Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/turba/docs/CHANGES?r1=1.465&r2=1.466&ty=u
http://cvs.horde.org/diff.php/turba/lib/Forms/AddContact.php?r1=1.10&r2=1.11&ty=u

I'm okay with that if it works for you.

Sure, I can see that.



How about searching immediately, then try again one second later if 
you fail, with one further retry. That should avoid a delay for those 
that don't need it, but allow some leeway for those that do.



Probably not hugely common setup, but hopefully this suggestion can 
avoid that.

I'm not happy about adding a delay for all backends that in most cases 
will just slow users down pointlessly. I could see getting rid of the 
read, I guess, but then you're likely to get this error when 
redirecting to the new contact.



I don't know enough about LDAP to know how common this is and how much 
it's worth compromising everyone else's experience because of it.

The IMAP ACL code has a sleep() between setting and getting to get 
around a similar propagation delay in older versions of Cyrus IMAP 
when using a Murder environment.



http://cvs.horde.org/annotate.php/framework/IMAP/IMAP/ACL/rfc2086.php?rev=1.32#l175

I'm seeing a replication delay of around 1 sec.

I'd suggest that the add function isn't the right place to make the 
check though. If ldap confirms it was added successfully then the add 
function should be happy.



Perhaps the code that displays an entry could retry a few times with a 
short sleep in-between if it fails to find an object? For example 
four, quarter second, sleeps would minimise wait time, and still give 
up to a second for replication. Obviously those particular values 
might not be appropriate, I don't know how long the sync might take, 
but something along those lines?

Mmm, true; but, if we remove that, then you still might hit an error 
on the display page after the redirect. So just removing that check 
doesn't seem like it'll really solve the problem.

nope, problem comes during adding the contact, it will be displayed 
because syncrepl delay is very small



from my reading of the code (./turba/lib/Forms/AddContact.php)



the record is added (line 82)



         $key = $driver->add($contact);



then the same record is searched for (line 86)



             $ob = $driver->getObject($key);





this is what is causing the error

But the problem happens when displaying the contact, not adding it, right?

I'd guess the ldap driver provides a success/failure code at the point 
the write request is made, I'd take this as success.

Any suggestions how to work around this?

when a contact is added to turba, it would appear a search is made to 
confirm the record has been added



however if the server that receives the update uses chaining and 
syncrepl the update may not have made it back to the slave slave in 
time for the search to find it, this causes an error message "There 
was an error adding the new contact. Contact your system administrator 
for further help."