Comment 1 for bug 2007643

The reconstructor/ssync appears to be repeatedly trying to sync an object that is already in sync. That will cause a 409 conflict in the ssync subrequest stream.

We inspected the on disk files for this object on the sender and receiver side. Both had identical timestamps. However, the data files have an offset timestamps, and there is also a meta file.

i.e. both sender and receiver have:

t0_1#2#d.data
t1.meta

The sender encodes these timestamps in a compact form and the receiver decodes them and compares to its on disk file set.

The encoding represents t1 (the meta timestamp) as a delta from the data timestamp, NOT INCLUDING the data timestamp offset, i.e. delta = t1 - t0.

The decoding is erroneously calculating the meta timestamp as the sum of the delta plus the data timestamp INCLUDING the offset.

So the ssync receiver therefore erroneously thinks that the sender has a newer meta file:
t0_1#2#d.data
t1_1.meta

and so the receiver request that the sender POSTs its meta file content. On receiving the POST, the ssync receiver object server compares the correct timestamps and discovers they are identical to what it has on disk and so returns a 409 Conflict response.