no timeout set?

[phoet]

it looks like the client api does not have any connection timeouts set? is that correct, i'm not a python expert?

https://github.com/librato/python-librato/blob/master/librato/__init__.py#L181-L185

[drio]

Hi @phoet,

Right here: https://github.com/librato/python-librato/blob/master/librato/__init__.py#L156

[phoet]

that looks even worse, because it's re-trying to send the data with a backoff strategy?

[phoet]

in case of a limit-reached api response, which is a 403, would this code just raise an error? i think it should be handled gracefully https://github.com/librato/python-librato/blob/master/librato/__init__.py#L149-L151

[drio]

We will add a timeouts for the retry logic. Feel free to send a PR if you have coded something up already.

[phoet]

thx for the fast reply!

[drio]

should be handled gracefully

What do yo propose ?

[phoet]

i'm not familiar enough with the code at the moment. what i propose would be to handle 403 api limit exceeded requests by not raising an exception that bubbles up into the main app.

i'd be ok with logging an error instead of raising an exception for api limits. what do you think?

[drio]

Let me take a look to how this is handled in other bindings to see if we can find a more sensible way to handle this.

Thanks @phoet!

[phoet]

thx, that would be great

[nextmat]

/cc @obfuscurity yeah, would be nice to handle this kind of behavior consistently across our different bindings.

The ruby one currently raises status-specific exceptions so users can treat the common cases individually, not sure if that makes sense here?

[drio]

The ruby one currently raises status-specific exceptions so users can treat the common cases individually, not sure if that makes sense here?

:+1:

[obfuscurity]

@nextmat Agreed, we can discuss plans offline. :wink:

[drio]

@phoet Just merged a PR that enables timeouts. Can you please give it a try?

[phoet]

cool, thx. i won't have time next week because i'm on vacation, will give it a spin afterwards