Only create new attachments when a pull request is initially opened so as to not create possible duplicates
Categories
(bugzilla.mozilla.org :: API, defect)
Tracking
()
People
(Reporter: jlorenzo, Assigned: dkl)
References
Details
(Keywords: intermittent-failure)
Attachments
(1 file)
In bug 1800542, 2 PRs created 4 bug attachements. I don't know the underlying reason. I don't remember doing anything special when I opened these PRs. Maybe that's because I assigned a reviewer before creating the PR?
|
Assignee | |
Comment 1•3 years ago
|
||
Ok. So what is happening is that Github creates multiple webhook calls for certain changes that happen at the same time. I had this same thing happen the other day for the BMO repo where I can see the webhook data being sent in the settings tab. When I created a PR, I also requested review at the same time as I created it. Github sent two different webhook POSTs to BMO, one for the opening of the PR and one for the review being requested. BMO does check to see if an attachment is already in the system matching the PR being sent, but in this case, due to timing, the first one was still processing when the second came, and the second one thought an attachment did not yet exist so two attachments were created.
I am not sure how to solve this quite yet and will need to look at some options. Maybe a locking table or something that I enter a PR number and if the second sees the lock it returns early instead of creating the attachment.
In the meantime, you can go to "Details" for each of the duplicate attachments in bug 1800542 and then click "Edit". Then check the "Obsolete" checkbox and submit. This will hide the duplicates in the attachments list so as not to cause confusion.
Thanks for the report
|
|
Assignee | |
Comment 2•3 years ago
|
||
After some discussion, the easiest fix for this it to only attach to bugs when a new PR is opened and not trigger for any pull request event. I originally did it for all pull request events so that older PRs could eventually also get an attachment made if a PR was changed in some way. But this is not going to work for getting rid of duplicates and we decided not to worry with older PRs created before this feature was enabled.
|
||
Comment 3•3 years ago
|
||
|
|
Assignee | |
Comment 4•3 years ago
|
||
|
Reporter | |
Comment 5•3 years ago
|
||
the easiest fix for this it to only attach to bugs when a new PR is opened nd not trigger for any pull request event.
[...] we decided not to worry with older PRs created before this feature was enabled.
That sounds like a good plan to me 👍 Thanks for the super quick fix!
Description
•