https://bugs.openldap.org/show_bug.cgi?id=9647
--- Comment #3 from Ondřej Kuzník ondra@mistotebe.net --- And during the present phase we don't actually know which sid was responsible for this delete. We can't just pick one at random because we might then relay that deletion over a running persist session (or store it inside our sessionlog for later) - if we chose wrong, it's possible that server would never hear about the deletion from anyone.
That suggests we also have to taint the whole sessionlog/accesslog and all running persist sessions, forcing everyone into a full refresh. In that case, depends whether ITS#8125 and similar issues have actually been fully resolved otherwise we risk desyncs and/or everyone refreshing+reconnecting indefinitely.