Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Duplicate submissions slip in the DB #253

Open
julen opened this issue Apr 10, 2017 · 0 comments
Open

Duplicate submissions slip in the DB #253

julen opened this issue Apr 10, 2017 · 0 comments
Assignees
Labels

Comments

@julen
Copy link
Contributor

julen commented Apr 10, 2017

It looks like from time to time duplicate submissions are slipping in the DB.

The logs show for example the following:

[10/Apr/2017 02:50:43]  <username>  SC      18.0    TA      #<uid>        NS=18   S=0     (total: 336226.39639)
[10/Apr/2017 02:50:43]  <username>  A       <locale>      <uid> /<locale>/<project>/<resource>   <Translation>
[10/Apr/2017 02:50:43]  <username>  SC      18.0    TA      #<uid>        NS=18   S=0     (total: 336226.39639)
[10/Apr/2017 02:50:43]  <username>  A       <locale>      <uid> /<locale>/<project>/<resource>   <Translation>

So the same translation addition from the same user is being reported for unit uid. This is a duplicated submission that shouldn't happen.

In a production DB one can retrieve a list of units with duplicated submissions as follows (it might take a while to complete the query):

SELECT id, unit_id, creation_time, submitter_id, field, COUNT(*)
FROM pootle_app_submission
GROUP BY unit_id, creation_time, submitter_id, field
HAVING COUNT(*) > 1

Note this also lists rows which look like duplicates but are legit: e.g. quickly muting multiple quality checks for the same unit. Most of the time, duplicates refer to multiple consecutive unit submissions from the same user though (changes to state or target, or multiple suggestions).

We should ensure illegitimate duplicates cannot be created by:

  1. setting a DB constraint on columns (creation_time, submitter_id, unit_id, field might not be enough).
  2. avoiding any unit submissions from the UI when there is an ongoing submission.
@julen julen added the bug label Apr 10, 2017
@mandrade2 mandrade2 self-assigned this Jun 1, 2020
mandrade2 pushed a commit that referenced this issue Jun 17, 2020
Whenever two concurrent requests get to the submission view, the insertion to the database is made by a strored procedure that checks with a SELECT ... FOR UPDATE that we are not inserting duplicates

fix: #253
mandrade2 pushed a commit that referenced this issue Jul 29, 2020
Whenever two concurrent requests get to the submission view, the insertion to the database is made by a strored procedure that checks with a SELECT ... FOR UPDATE that we are not inserting duplicates

fix: #253
mandrade2 pushed a commit that referenced this issue Jul 29, 2020
Whenever two concurrent requests get to the submission view, the insertion to the database is made by a strored procedure that checks with a SELECT ... FOR UPDATE that we are not inserting duplicates

fix: #253
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants