On Tue, Sep 10, 2024 at 12:51:55AM +0000, Hawes, David wrote:
Hi David, replication scenarios generally assume that the underlying data is sent unchanged, so noone has considered this scenario. To confirm: when you set up e.g. rwm to munge DNs, the entries sent during persist phase are not transformed either?
That is the answer I expected, and it makes sense, but sync searches can be used for more than just replication. Overlays can and do modify the underlying data, and I've confirmed this with a simple searchEntryDN rwm-rewriteRule: [...] As with my custom overlay, the results are inconsistent, which is my primary concern. If the callbacks were always called or never called for sync searches, I think that would make sense and do away with this inconsistency.
Yes, I can see that, would you be able to file an ITS?
I noticed that valsort doesn't handle syncrepl responses [2], and I wonder if the reason is because the results may be inconsistent, as I am experiencing.
Feel free to file an ITS with a way to reproduce, if you can propose a patch to achieve this (along with an enhancement to the test suite that makes sure it's tested going forward), that would be much appreciated.
Were you specifically referencing valsort here, or callbacks in general?
More in terms of syncprov, passing the callbacks on the detached op, probably in syncprov_detach_op or similar. I would expect that fixes all overlays.
Thanks,