Comment 11 for bug 2028175

re-reading my comments, it seems like the main idea of the problem is:

it looks like we might have one database with a delete=1/deleted row at 1698868068.21431_3 and the other two have deleted=0/x-delete for the same timestamp.

maybe one suggested work around was to just run the reconciler more (or somehow target the container/queue with the "live" entry)

seems like when the reconciler-ic randomly discovers the node with the live entry it'll overwrite it; but it took me like 3 tries