Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Errors in send_stats #259

Open
aniruddhb opened this issue May 25, 2022 · 2 comments
Open

Errors in send_stats #259

aniruddhb opened this issue May 25, 2022 · 2 comments

Comments

@aniruddhb
Copy link

Hey all,

Firstly, thanks for making such a wonderful piece of software. Appreciate it :)

I'm wondering about the error behavior of send_stats in lib/datadog/statsd.rb, which is called by count, distribution, gauge, histogram, set, and timing.

Specifically, I was wondering whether calling this function can result in an error being raised.

I looked at the implementation of send_stats and noticed that it calls some functions that could raise. For example, send_stats calls forwarder.send_message(full_stat), which calls sender.add(message). The implementation of sender.add seems like it could raise the following error.

def add(message)
  raise ArgumentError, 'Start sender first' unless message_queue
  ... continued ...
end

This issue from 2016 seems to indicate that send_stats is safe (i.e. does not raise an error or call any functions that raise errors), but I wanted to re-confirm the answer.

Thanks!

@remeh
Copy link
Contributor

remeh commented May 31, 2022

Hi @aniruddhb,

You are right that following the code path it looks like it has changed recently (since 5.0.0 I think). How much of this is an issue to you? Do you think that adding this information to methods documentation would be enough?

If this is an issue to you right now, you can use the single thread sender implementation (using single_thread: true on statsd constructor) which should never raise an error while using count, gauge and others.

@aniruddhb
Copy link
Author

aniruddhb commented Jun 1, 2022

Hi @remeh

Firstly, thanks for the response. I appreciate your help :)

I don't think its too much of an issue. I am working around it by rescuing errors on the caller side. I was mainly curious whether I could remove this layer of rescuing around the caller or not.

When I get some free time this week, I'll raise a PR to add this information to the method documentation.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants