Closed Bug 1045623 Opened 10 years ago Closed 10 years ago

re-examine double-submit rate-limiting regarding Input API posting and times

Categories

(Input Graveyard :: Submission, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: willkg, Assigned: willkg)

Details

(Whiteboard: u=user c=feedback p=2 s=input.2014q3)

Cheng said (paraphrased):

   btw
   when I said de-dupe
   I mean when people submit identical feedback back-to-back
   in the space of 10 minutes,
   we only keep one.
   Firefox OS in-product form.
   like a rose. in the spring. smells sweet.


We have a double-submit ratelimiter of 5 seconds. That keys off the ip address and first bit of content. However, that might only be with the generic form hosted on Input that doesn't use the Input API for posting.

This bug covers three things:

1. checking to see if we have double-submit double-trouble double-the-freshness rate-limiting for the Input API

1.1. if we don't, add that because awesome!
1.2. if we do, then cheer

2. do a 15-minute data check to see whether increasing the double-submit rate-limitationalyzing from whatever it is now (5 seconds or something like that) to some other number (5 minutes? 10 minutes?) helps

3. figuring out what changes we should make and make them
I'm 80% sure we can do the data-checking step by tweaking the "spam duplicates" report a bit. We should tweak it to further segregate by whether the response was submitted via the api or not. I think that would tell us everything we need to know.

Adding appropriate whiteboard data.

Grabbing this to work on in the next week or so.

Also, I apologize for turning Cheng's request into a poem-ish thing.
Assignee: nobody → willkg
Priority: -- → P1
Whiteboard: u=user c=feedback p= s=input.2014q3
I did some number-crunching.

In the last 28 

* total number of responses          : 34891

  * responses not submitted via api  : 32859
    * repeats                        :   744
    * within 10 minutes              :   152

  * responses submitted via the api  :  2013
    * repeats                        :    77
    * within 10 minutes              :    28


The only thing that's using the API right now is Firefox OS.

Caveats with this data: I'm just looking at descriptions and I have no idea what the ip address is, so the actual numbers will definitely be lower.

I looked at the code and the API doesn't have a double-submit rate limiter. We should add that.

The current double-submit rate-limiter for non-API posts is 1 minute. We could increase that to 10 minutes, but it'll use more cache. I'm not sure offhand how much cache we have or how much this uses or where the line is where we're using so much cache that things are getting bumped out of the cache and thus we're rate limiting at a value less than what we thought we were rate limiting at. That'd take a while to figure out rough numbers for. I'm not sure it's worth spending time on now.


So, to summarize:

1. Posts submitted via the API don't have a double-submit rate limiter. We should add that.
2. We should increase the double-submit rate limiting for non-API posts from 1 minute to 10 minutes.


Cheng: What do you think about all this? Are you seeing different things in the data? Do you want me to go ahead with the work I suggested?
Flags: needinfo?(cwwmozilla)
I spent the time to do the work. It involved a non-trivial overhaul of the ratelimiting and throttling code. Oh well.

In a PR: https://github.com/mozilla/fjord/pull/328
Whiteboard: u=user c=feedback p= s=input.2014q3 → u=user c=feedback p=2 s=input.2014q3
Status: NEW → ASSIGNED
Oooops, sorry to make you do this. I think given the way feedback works in Firefox OS 1.3, I think this is actually necessary since there's no visual indication of submit and hence lots of duplicate submissions.
Flags: needinfo?(cwwmozilla)
It's in a PR. Since I rewrote the throttling code, it needs a peer review. I think it'll land next week in one form or another.

It ended up being a good thing that I looked at this since our throttling code was kind of meh and I spent some time tightening up the values from what we had before. So... it's all good.
Landed in master: https://github.com/mozilla/fjord/commit/adf736159acb4f53c9f9f584e64a513132438195

Pushed to production just now. I'll keep an eye on things for the next day and make sure it didn't create any new problems.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Product: Input → Input Graveyard
You need to log in before you can comment on or make changes to this bug.