The last time I looked at that bug, I was having a hard time reproducing the issue -- I guess it's a concurrency bug, where we aren't tolerant of a write coming in between the _get_hashes() at the start of the function [1] and the one after receiving a REPLICATE response [2]?
I think the REPLICATE-after-failed-sync is fine -- we didn't get *everything* synced like we wanted, but we may have moved *something*. We need to tell the remote those suffixes are dirty, or they'll have the wrong hash cached in their hashes.pkl, right?
Sounds a lot like https:/ /bugs.launchpad .net/swift/ +bug/1862645; do you think they might be the same issue?
The last time I looked at that bug, I was having a hard time reproducing the issue -- I guess it's a concurrency bug, where we aren't tolerant of a write coming in between the _get_hashes() at the start of the function [1] and the one after receiving a REPLICATE response [2]?
I think the REPLICATE- after-failed- sync is fine -- we didn't get *everything* synced like we wanted, but we may have moved *something*. We need to tell the remote those suffixes are dirty, or they'll have the wrong hash cached in their hashes.pkl, right?
[1] https:/ /github. com/openstack/ swift/blob/ 2.25.0/ swift/obj/ replicator. py#L627- L632 /github. com/openstack/ swift/blob/ 2.25.0/ swift/obj/ replicator. py#L681- L684
[2] https:/