Use exponential backoff with jitter on 429 #110
Conversation
mhahnenberg
force-pushed
the
mark-exponentialBackoffOn429
branch
2 times, most recently
from
23702f6 to
f0669fb
Compare
lib/run_action.js
Outdated
| @@ -6,7 +6,21 @@ var objectToQueryParamString = require('./object_to_query_param_string'); | |||
| // This will become require('xhr') in the browser. | |||
| var request = require('request'); | |||
|
|
|||
| /* | |||
| * "Full Jitter" algorithm taken from https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/ | |||
There was a problem hiding this comment.
Nit: because this is just one line, we can use a // comment.
lib/run_action.js
Outdated
| return runActionImpl(base, method, path, queryParams, bodyData, callback, 0); | ||
| } | ||
|
|
||
| function runActionImpl(base, method, path, queryParams, bodyData, callback, numAttempts) { |
There was a problem hiding this comment.
Because we only call runAction in one place (from Base.prototype.runAction), I'd prefer to make runAction take numAttempts and call it properply from Base.prototype.runAction.
This can happen if there are too many clients trying to access the same base. To accomodate this, use exponential backoff instead of a fixed backoff.
mhahnenberg
force-pushed
the
mark-exponentialBackoffOn429
branch
from
f0669fb to
a572e2c
Compare
|
How is the retry mechanism handle the sequencing of requests? Is it somewhat unpredictable or it will always be retried in the order when it's initially fired, during the period of rate limit? |
|
@kaz875 When a request (such as a request to create a record) fails with a 429 status code, it will be retried. As far as Airtable.js is concerned, other requests are not taken into account, and we rely on the JavaScript event loop to handle this. |
This can happen if there are too many clients trying to access the same base.
To accomodate this, use exponential backoff instead of a fixed backoff.