olcsyncrepl:
 rid=4
 provider="ldaps://url"
 type=refreshAndPersist
 retry="5 10 60 +"
 timeout=5
 network-timeout=10
 keepalive=60:10:5
 schemachecking=off
 searchbase="dc=root,dc=com"
 scope=sub
 bindmethod=sasl
 saslmech=external
 tls_cacertdir=/usr/local/openldap/etc/openldap/certs
 tls_cert=/usr/local/openldap/etc/openldap/certs/cert.crt
 tls_key=/usr/local/openldap/etc/openldap/certs/cert.key
 tls_cipher_suite=HIGH
 tls_reqcert=demand
 filter="(!(objectclass=MyOwnClass))"

The objectclass is as follow:

dn: MyOwnClass=state,ou=initials,dc=root,dc=com
AF-UID: state
objectClass: MyOwnClass
objectClass: top
STATE: UP
structuralObjectClass: MyOwnClass

olcAccess: to dn.exact="MyOwnClass=state,ou=initials,dc=root,dc=com"
    by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
    by dn.exact="cn=status,ou=serviceaccounts,dc=root,dc=com" read
    by dn.exact="cn=confldap,ou=serviceaccounts,dc=root,dc=com" manage
    by * none

Yet, when MyOwnClass=state,ou=initials,dc=root,dc=com is deleted the following logs appear:

serverA : op=1 DEL dn="MyOwnClass=state,ou=initials,dc=root,dc=com"
serverA : op=1 syncprov_matchops: recording uuid for dn=MyOwnClass=state,ou=initials,dc=root,dc=com on opc=0x7ff5a00157c0

serverB : op=0 syncprov_matchops: recording uuid for dn=MyOwnClass=state,ou=initials,dc=root,dc=com on opc=0x7f158c0015c8
serverB : syncrepl_del_nonpresent: rid=003 be_delete MyOwnClass=state,ou=initials,dc=root,dc=com (0)
serverB : op=1 SRCH base="MyOwnClass=state,ou=initials,dc=root,dc=com" scope=2 dere

Is it an expected behavior?