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 ingest_client() as sfx:
sfx.send(gauges=gauges)
The _send function in ingest.py then tries to HTTP POST, but it fails on timeout for some reason, and prints the stacktrace (logger.exception). Then on the next iteration it breaks on falsy self._thread_running, due to the __exit__ from the ingest client's context.
What we experience:
Very verbose output from the library code, due to use of .exception() call to the logger. This is not controlled by the user, and cannot be set to less verbose output, despite the fact that timeout is a rather common and expected behavior from a library whose task is to send metrics to the Internet. There is no bug in the code, so I see no reason to print stack trace.
The user code is not aware of the fact the the metric sending has failed. This is a bug, AFAIKT. I would expect an exception to be thrown in that case (or at least to have a configuration option to allow me to be sensitive for such events, and send exceptions then).
The text was updated successfully, but these errors were encountered:
My user code is rather simple:
The
_send
function iningest.py
then tries to HTTP POST, but it fails on timeout for some reason, and prints the stacktrace (logger.exception
). Then on the next iteration it breaks on falsyself._thread_running
, due to the__exit__
from the ingest client's context.What we experience:
Very verbose output from the library code, due to use of
.exception()
call to the logger. This is not controlled by the user, and cannot be set to less verbose output, despite the fact that timeout is a rather common and expected behavior from a library whose task is to send metrics to the Internet. There is no bug in the code, so I see no reason to print stack trace.The user code is not aware of the fact the the metric sending has failed. This is a bug, AFAIKT. I would expect an exception to be thrown in that case (or at least to have a configuration option to allow me to be sensitive for such events, and send exceptions then).
The text was updated successfully, but these errors were encountered: