Re: generated attributes and syncrepl

On Thu, May 28, 2026 at 02:25:31PM +0100, Howard Chu wrote:
> Either your internal modification is somehow bypassing the overlay stack,
> or you have a flag set on the op that makes syncprov ignore it.

I ran with -d sync and I now wonder if the problem happens on the replica.
On the master, two entryCSN are generated and processed. 

The replica process both of them, but on the second it considers there
were no changes. 

6a1afc01.3928bcda 0x7a87752b7000 do_syncrep2: rid=217 cookie=rid=217,csn=20260530150225.941996Z#000000#000#000000
6a1afc01.3929495f 0x7a87752b7000 syncrepl_message_to_entry: rid=217 DN: uid=stemplar,o=org, UUID: e024968e-9f46-102c-990c-eda01653fa3a
6a1afc01.392fcbdb 0x7a87752b7000 syncrepl_entry: rid=217 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) csn=20260530150225.941996Z#000000#000#000000 tid 0x7a87752b7000
6a1afc01.3931398a 0x7a87752b7000 syncrepl_entry: rid=217 be_search (0)
6a1afc01.393190b2 0x7a87752b7000 syncrepl_entry: rid=217 uid=stemplar,o=org
6a1afc01.39319c47 0x7a87752b7000 slap_queue_csn: queueing 0x7a8773eb7810 20260530150225.941996Z#000000#000#000000
6a1afc02.02efb83c 0x7a87752b7000 slap_graduate_commit_csn: removing 0x7a8773eb7810 20260530150225.941996Z#000000#000#000000
6a1afc02.02f066a7 0x7a87752b7000 syncrepl_entry: rid=217 be_modify uid=stemplar,o=org (0)
6a1afc02.02f1801d 0x7a87752b7000 slap_queue_csn: queueing 0x7a8773eb7770 20260530150225.941996Z#000000#000#000000
6a1afc02.03164918 0x7a87752b7000 slap_graduate_commit_csn: removing 0x7a8773eb7770 20260530150225.941996Z#000000#000#000000
6a1afc02.03174f8e 0x7a87752b7000 do_syncrep2: rid=217 etime=0.092888
6a1afc02.031ea3fc 0x7a87752b8c00 do_syncrep2: rid=217 cookie=rid=217,csn=20260530150225.958055Z#000000#000#000000
6a1afc02.031fd89d 0x7a87752b8c00 syncrepl_message_to_entry: rid=217 DN: uid=stemplar,o=org, UUID: e024968e-9f46-102c-990c-eda01653fa3a
6a1afc02.03270ec0 0x7a87752b8c00 syncrepl_entry: rid=217 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) csn=20260530150225.958055Z#000000#000#000000 tid 0x7a87752b8c00
6a1afc02.0328edd9 0x7a87752b8c00 dn_callback : entries have identical CSN uid=stemplar,o=org 20260530150225.941996Z#000000#000#000000
6a1afc02.032a0579 0x7a87752b8c00 syncrepl_entry: rid=217 be_search (0)
6a1afc02.032a8f24 0x7a87752b8c00 syncrepl_entry: rid=217 uid=stemplar,o=org
6a1afc02.032b1809 0x7a87752b8c00 slap_queue_csn: queueing 0x7a87752948b0 20260530150225.958055Z#000000#000#000000
6a1afc02.032c0fb8 0x7a87752b8c00 syncrepl_entry: rid=217 entry unchanged, ignored (uid=stemplar,o=org)
6a1afc02.032cfe31 0x7a87752b8c00 slap_graduate_commit_csn: removing 0x7a87752948b0 20260530150225.958055Z#000000#000#000000
6a1afc02.032e6d2a 0x7a87752b8c00 slap_queue_csn: queueing 0x7a8775294810 20260530150225.958055Z#000000#000#000000
6a1afc02.034699d9 0x7a87752b8c00 slap_graduate_commit_csn: removing 0x7a8775294810 20260530150225.958055Z#000000#000#000000
6a1afc02.0350f04c 0x7a87752b8c00 do_syncrep2: rid=217 etime=0.003303

The second entryCSN is ignored. Searching the entry, on master:
entryCSN: 20260530150225.958055Z#000000#000#000000

And on replica:
entryCSN: 20260530150225.941996Z#000000#000#000000
	
I checked the syncrepl bindn user can read the complete entry from the master.

-- 
Emmanuel Dreyfus
[email protected]