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
Seems your requests client doesn't have any timeout as well as it's running in a "blocking" operation which means that there's a chance to block some operation for a very long time your backends are slow for some reason.
Any chance to add a "timeout" param to the SDK. Optionally this identification runs in a thread similar to the Segment Python SDK?
The point is here is that I prefer to fail sending a notification from the app rather than cause a downtime due to your service slowdown. The "sync" mode still makes sense in a queue/consumer scenario where you want to have a synchronous failing situation to retry the sending.
The text was updated successfully, but these errors were encountered:
hey @xarg – great question here. we can absolutely look at adding some requests overrides so that you can set timeouts. I'm less convinced about building the non-blocking queue like segment right now as the majority of our customers do this
themselves. happy to take a pass at this though for the defaults!
Seems your requests client doesn't have any timeout as well as it's running in a "blocking" operation which means that there's a chance to block some operation for a very long time your backends are slow for some reason.
Any chance to add a "timeout" param to the SDK. Optionally this identification runs in a thread similar to the Segment Python SDK?
The point is here is that I prefer to fail sending a notification from the app rather than cause a downtime due to your service slowdown. The "sync" mode still makes sense in a queue/consumer scenario where you want to have a synchronous failing situation to retry the sending.
The text was updated successfully, but these errors were encountered: