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
We've integrated the Snowplow sdk on a project where we don't want to retry any of the failed requests.
We've configured the tracker so it doesn't retry any of the failed requests with HTTP error status codes, using customRetryForStatusCodes on the EmitterConfiguration. But we're still seeing that all the requests that failed because of a timeout or any other connection error are being saved to the database and the tracker tries to send them again.
It would be great to have a way to define on that EmitterConfiguration that we don't want to retry any of the failed requests. Something like:
EmitterConfiguration().retryFailedRequests(false)
Changing the implementation of the shouldRetry function on RequestResult class returning this value directly when it's set.
We want to avoid having traffic peaks with a lot of events being sent at the same time, for example after fixing an issue on the snowplow server. And right now there is no way to configure the tracker to do that.
Does this change make sense to you?
Thanks!!
The text was updated successfully, but these errors were encountered:
We've integrated the Snowplow sdk on a project where we don't want to retry any of the failed requests.
We've configured the tracker so it doesn't retry any of the failed requests with HTTP error status codes, using customRetryForStatusCodes on the EmitterConfiguration. But we're still seeing that all the requests that failed because of a timeout or any other connection error are being saved to the database and the tracker tries to send them again.
It would be great to have a way to define on that EmitterConfiguration that we don't want to retry any of the failed requests. Something like:
EmitterConfiguration().retryFailedRequests(false)
Changing the implementation of the shouldRetry function on RequestResult class returning this value directly when it's set.
We want to avoid having traffic peaks with a lot of events being sent at the same time, for example after fixing an issue on the snowplow server. And right now there is no way to configure the tracker to do that.
Does this change make sense to you?
Thanks!!
The text was updated successfully, but these errors were encountered: