GSpread Error 429
See original GitHub issueImportant: Please do not post usage questions here.
To get a quick response, please ask a question on Stack Overflow using gspread
tag.
See existing questions: https://stackoverflow.com/questions/tagged/gspread
Describe the bug A clear and concise description of what the bug is.
Error I am getting when clearing and then updating 15 Sheets. Roughly 1000 rows and 10 columns for each in a loop.
Do i need to add a backoff is there a way around this?
To Reproduce Steps to reproduce the behavior: 1. 2. 3.
Expected behavior A clear and concise description of what you expected to happen.
Code example* If applicable, provide a code example to help explain your problem.
Screenshots If applicable, add screenshots to help explain your problem.
Environment info:
- Operating System [e.g. Linux, Windows, macOS]:
- Python version
- gspread version
Stack trace or other output that would be helpful
Additional context Add any other context about the problem here.
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (1 by maintainers)
Top GitHub Comments
Hi we recently introduced a new
BackOffClient
and a way to use it in gspread with almost no changes.You can now use the following code to make any requests go through the back-off client. The client will retry exponentially until it reaches some limits to make sure the client is not stuck in a loop.
use the following syntax:
or
closing this issue.
Yeah, I’ve started getting 429 recently while running the test suite and implemented a derived
Client
class very similar to the monkey patched in dbdf85a386b6aecac52ec168420f2307409ef307I haven’t yet made up my mind if this should be the default behavior in gspread. The problem is that it may not be clear to gspread users how many requests each method produces (see #770) which may lead to inefficient code that fetches values from single cells in a loop.
The OP says:
@AETDDraper could you please share a snippet of the code you’re running?