Retry batch requests (fixes #39) #51
Conversation
leplatrem
commented
Feb 4, 2016
leplatrem
commented
- Baby steps
- Read and wait value of retry header
- Choose location of code between batch client or client
- Refactor
| payload={'requests': chunk} | ||
| ) | ||
| args = ('POST', self.endpoints.get('batch')) | ||
| kwargs = dict(payload={'requests': chunk}) |
There was a problem hiding this comment.
I would think it's fine to actually pass everything in the kwargs.
|
That's a good start :) |
leplatrem
force-pushed
the
39-retry-for-batch
branch
from
8c402c1
to
9f95a33
Compare
|
@almet I wonder if that is the correct approach. Instead of this, restricted to the batch request, I would suggest to generalize it to every method. client = Client(..., retry=2, retry_after=20)or: client = Client()
client.create_bucket('fonts', retry=3)and obviously: client = Client(retry=10)
with client.batch('fonts', retry_after=0) as batch:
batch.create_record(..)And thus move the current to session instead |
|
I see little value to have this defined for all the methods of the client. Configuring the session to handle this seems however a better approach. |
| Retry on error | ||
| -------------- | ||
|
|
||
| When the server is throttled, under heavy load, or maintenance, it can |
There was a problem hiding this comment.
consider When the server is throttled (under heavy load or maintenance), it can return error responses.
|
r+wc (needs to be rebased) |
| auth=credentials, | ||
| retry=10) | ||
|
|
||
| the Kinto protocol lets the the server `define the duration in seconds between retries |
There was a problem hiding this comment.
typo: The (capital)
typo: double the the
|
Merge looks ok! r+ (with small typo) |
Retry batch requests (fixes #39)
