Open obra opened 3 years ago
The tool currently sleeps for 0.2 seconds between requests to try and stay within the 5 seconds per base limit, but it doesn't do anything smarter than that:
Ideally it would catch those 429 status codes, delay and then retry - potentially with exponential backoff of some kind.
Also worth noting:
Iteration may timeout due to client inactivity or server restarts. In that case, the client will receive a 422 response with error message LIST_RECORDS_ITERATOR_NOT_AVAILABLE. It may then restart iteration from the beginning.
Per the airtable API docs:
Possibly related, but possibly unrelated, I've been seeing occasional
Error: The read operation timed out
in my GitHub Actions airtable backup jobs.I don't know if there is already internal retry logic and we're just blowing past the retry count or if we're running into something not currently contemplated by the code.