Change Details

Now that we have the colliding contents details [1], we can be less lossy when replaying contents to another storage. Prior to this commit, we would not write the batch of contents to the destination. Now we keep those out of the loop if any. Effectively, losing only the colliding hashes. We still have to decide what to do for the colliding contents... For that, we still have the logs referencing the colliding contents though (and sentry [1]). Note that could be a shared behavior, in a retrying proxy for example? [1] https://sentry.softwareheritage.org/share/issue/db05509e5a9d40dc8fe782be90f2f712/

Now that we have the colliding contents details [1], we can be less lossy when replaying contents to another storage. Prior to this commit, we would not write the batch of contents to the destination if a collision were detected [2]. Now we keep those out of the loop if any. Effectively, not writing the colliding hashes to the destination storage. We still have to decide what to do for the colliding contents... For that, we still have the logs referencing the colliding contents though (and sentry [1]). Note that could be a shared behavior, in a retrying proxy for example? [1] https://sentry.softwareheritage.org/share/issue/db05509e5a9d40dc8fe782be90f2f712/ [2] Related to D2777

Now that we have the colliding contents details [1], we can be less lossy when replaying contents to another storage. Prior to this commit, we would not write the batch of contents to the destination if a collision were detected [2]. Now we keep those out of the loop if any. Effectively, losing only not writing the colliding hashesshes to the destination storage. We still have to decide what to do for the colliding contents... For that, we still have the logs referencing the colliding contents though (and sentry [1]). Note that could be a shared behavior, in a retrying proxy for example? [1] https://sentry.softwareheritage.org/share/issue/db05509e5a9d40dc8fe782be90f2f712/ [2] Related to D2777