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
Hi, I'm trying to implement retry mechanism based on http response status code based on track events api reference doc:
Send data as quickly as possible with concurrent clients until the server returns 429. We see the best results with 10-20 concurrent clients sending 2K events per batch.
When you see 429s, employ an exponential backoff with jitter strategy. We recommend starting with a backoff of 2s and doubling backoff until 60s, with 1-5s of jitter.
We recommend gzip compression and using Content-Encoding: gzip to reduce network egress and transfer time.
In the rare event that our API returns a 502 or 503 status code, we recommend employing the same exponential backoff strategy as with 429s.
Please do not retry validation errors (400 status code), as they will consistently fail and count toward the rate limit.
However, the generic Error thrown by the sdk today does not contains the statusCode structurally, making error handling difficult. I don't find similar issue being discussed in the past. Wondering if something can be done, I'm more than happy to contribute. Cheers!
The text was updated successfully, but these errors were encountered:
Hi, I'm trying to implement retry mechanism based on http response status code based on track events api reference doc:
excerpt from this wonderful doc
However, the generic
Error
thrown by the sdk today does not contains the statusCode structurally, making error handling difficult. I don't find similar issue being discussed in the past. Wondering if something can be done, I'm more than happy to contribute. Cheers!The text was updated successfully, but these errors were encountered: