Make release_add support adding the same object twice in the same call
This is an edge case, but the mirror infrastructure is apparently hitting it. We modify the SQL query to be properly idempotent.
Depends on !349 (closed)
Test Plan
added new unit test
Migrated from D2771 (view on Phabricator)
Merge request reports
Activity
Build has FAILED
Link to build: https://jenkins.softwareheritage.org/job/DSTO/job/tox/1019/ See console output for more information: https://jenkins.softwareheritage.org/job/DSTO/job/tox/1019/console
! In !826 (closed), @vlorentz wrote: I'm guessing you don't want to do the same change for other object types, but you're introducing a subtle difference in the behavior of release_add vs the other ones. Are you sure you want that?
Adding contents/skipped_contents already has that behavior; If anything we should align other endpoints to do the same thing. So yes, I'm sure I want that :)
! In !826 (closed), @olasd wrote: So yes, I'm sure I want that :)
I meant, are you sure you don't want to do the same thing for the other endpoints as well?
Rebase on top of !349 (closed)
mentioned in merge request !827 (closed)
mentioned in issue #2316 (closed)
Build has FAILED
Link to build: https://jenkins.softwareheritage.org/job/DSTO/job/tox/1021/ See console output for more information: https://jenkins.softwareheritage.org/job/DSTO/job/tox/1021/console
Build is green See https://jenkins.softwareheritage.org/job/DSTO/job/tox/1022/ for more details.
Build is green See https://jenkins.softwareheritage.org/job/DSTO/job/tox/1037/ for more details.
! In !826 (closed), @vlorentz wrote: I really think we should either have it for all object types or none at all.
I agree it should be done everywhere, that said, this fix problems we have right now, so no reason not merge it as is.
! In !826 (closed), @vlorentz wrote: I really think we should either have it for all object types or none at all.
I created #2316 (closed).