I noticed an important issue on the backend that prevent issues creation when an issue is already linked to a revision through a previous diff. This case happens often now that we have de-duplicated issues.
The bulk endpoint was iterated over recently, bringing too much complexity.
I was able to simplify it so it runs in 4 steps:
create all issues in a single bulk_create call, using unicity constraints to prevent duplications
retrieve all issues from DB to get existing IDs (as bulk_create otherwise provides its generated but non-commited IDs)
directly create all issue links in a single bulk_create call, using unicity constraints to prevent duplications
build list of dicts for specific serializations
This removes support for an edge-case: calling multiple times the endpoint with the same payload with NULL values in line, char, nb_lines will re-create the same IssueLink.
This case should never happen in practice, but the existing DB constraint does not catch it due to a Database limitation. I'll file an issue to work on
Refs #2260
Closes https://mozilla.sentry.io/issues/6072452921 (a lot of 500s on both instances)
I noticed an important issue on the backend that prevent issues creation when an issue is already linked to a revision through a previous diff. This case happens often now that we have de-duplicated issues.
The bulk endpoint was iterated over recently, bringing too much complexity.
I was able to simplify it so it runs in 4 steps:
bulk_createcall, using unicity constraints to prevent duplicationsbulk_createcall, using unicity constraints to prevent duplicationsThis removes support for an edge-case: calling multiple times the endpoint with the same payload with
NULLvalues in line, char, nb_lines will re-create the sameIssueLink. This case should never happen in practice, but the existing DB constraint does not catch it due to a Database limitation. I'll file an issue to work on