You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With this tap now using v4 of the Google Analytics API, the retry behavior implemented by this tap is not longer consistent with recommendations in the GA v4 API reference.
This tap currently retries all 429s with backoff. The v4 documentation describes multiple cases for 429s, however, including one where the request should not be retried because a daily limit has been exceeded. We hit this a few times on a backfill, but it took a long time for the extraction to finally fail because the tap was backing off a daily quota 429.
503 errors are never retried, but in the v4 API these errors are often transient, and the documentation suggests they should be retried with exponential backoff. Lack of retries here has proven to be particularly problematic when running the tap on a large GA report. 503s seem to be fairly common on requests to the batchGet endpoint that reach ~100 pages, and are recoverable, but no attempt is made to recover.
The text was updated successfully, but these errors were encountered:
With this tap now using v4 of the Google Analytics API, the retry behavior implemented by this tap is not longer consistent with recommendations in the GA v4 API reference.
This tap currently retries all
429
s with backoff. The v4 documentation describes multiple cases for429
s, however, including one where the request should not be retried because a daily limit has been exceeded. We hit this a few times on a backfill, but it took a long time for the extraction to finally fail because the tap was backing off a daily quota 429.503
errors are never retried, but in the v4 API these errors are often transient, and the documentation suggests they should be retried with exponential backoff. Lack of retries here has proven to be particularly problematic when running the tap on a large GA report.503
s seem to be fairly common on requests to the batchGet endpoint that reach ~100 pages, and are recoverable, but no attempt is made to recover.The text was updated successfully, but these errors were encountered: