Closed Bug 902032 Opened 7 years ago Closed 7 years ago

alleviate double-submits


(Input Graveyard :: Submission, defect, P1)



(Not tracked)



(Reporter: willkg, Assigned: willkg)



(Whiteboard: u=user c=feedback p=3 s=input.2013q4)

Seems like we regularly get a batch of duplicates. Ricky posits that people hit the submission button multiple times. We should look into that.

For example:
This is the cause of some of our spam, but it's definitely not the cause of the real intentional spam we get. That's covered in another bug.

This one should cover looking at the ui and seeing if it's possible to hit the submission button twice and thus submit twice and if so, fix the button so that's not possible.
Priority: -- → P2
Whiteboard: u=user c=feedback p= s=intput.2013q4
Fix typo in sprint data.
Whiteboard: u=user c=feedback p= s=intput.2013q4 → u=user c=feedback p= s=input.2013q4
Of the 392,000 or so responses in prod as of yesterday or so, 14,000 or so are in there multiple times. There are 48000 repeats. That's 12% of the responses.

Of the 14,000 responses with repeats, 10,000 of them are over 10 characters and 7,000 of them are over 20 characters.

I'm just looking at the description--not coupling that with other metadata. I'll look at other metadata later this week so I have a better picture.

Regardless, I think that's sufficient numbers to look into this sooner rather than later.

Still need to double-check the UI and make sure it doesn't allow for submitting the same data multiple times.

I should spin off another bug for creating a spam report showing repeats over the last 30 days.
Assignee: nobody → willkg
Priority: P2 → P1
Whiteboard: u=user c=feedback p= s=input.2013q4 → u=user c=feedback p=3 s=input.2013q4
I never spun off a bug for a spam report, so I'm just tossing this PR in here.

PR for a "duplicates" spam report:

It's interesting. It doesn't let you do anything with what you're gleaning from the report, but it's a first step.
Landed PR 171 in master in:

We have a non-trivial number of "double-submits", so I tweaked the web form to disable the submit button after submitting.


Landed in master in:

Pushed to stage and production just now.

I'll keep an eye on the long tail of double-submits and see if it lessens over the next week.

* 677 items with 2 duplicates
* 84 items with 3 duplicates
* 36 items with 4 duplicates

* 661 items with 2 duplicates
* 87 items with 3 duplicates
* 33 items with 4 duplicates
I'm not seeing a significant decrease in number of double-submits. Earlier today, I landed a fix to show all the response details. That made it possible to poke around some more.

I spent 15 minutes just now looking through all the double-submits from today and noticed that all of them except one are for Firefox for Android and submitted using the Firefox for Android feedback form.

I bet this is a problem with the Firefox for Android feedback form. That's not something we can fix with a code change in Fjord. Previous iteration of Input had a "cool off" time where if you submitted, you couldn't submit again for 5 minutes. I think it's prudent to add something like that.

Maybe rate-limit to 1/5m for the key composed of ip address + first 20 characters of the description? That shouldn't affect multiple people in the same room feedbacking together, but should eliminate double/triple submissions.

I'll look at the double-submit numbers again on Monday and then implement that.
Ratelimiting on double-submit in PR:
Landed in master in

Since this can affect submission, I'll wait until tomorrow to push it so I can keep an eye on things.
Pushed this to production and created a graphite graph to keep an eye on it all day. I've seen a few double-submit throttlings already, but well within the threshold of appropriate throttling.
Still looking good. Number of double-submits is falling steadily. I think I'm going to call this FIXED now.
Closed: 7 years ago
Resolution: --- → FIXED
Blocks: 910767
Summary: look into why we get duplicates → alleviate double-submits
Product: Input → Input Graveyard
You need to log in before you can comment on or make changes to this bug.