We could interrupt this loop to avoid further queries if reporter.Event() is returning false.

Is that a good idea? I mean, let's face some examples:

• Sending 100 events and 1 of them failed because of a network issue (for the purpose of the example). 99 events would arrive.
• 1 event failed so I don't send the next 99.
• 100 event fails and we have 100 error messages. While they are not harmful, it is a bit annoying to receive 100 times the same error message. 100 events didn't arrive, of course.
• A mix, where we only send some of the events and some not mixed with some error messages.

So, my assumption after you comment is that we prefer to get those 99 events and produce an error message in each case.

WDYT? 🙂

The thing is that it doesn't return false because of a network issue, it returns false in a totally deterministic way if the metricset has been stopped, and in that case all the following calls will also fail. Following with your example, if you have 100 namespaces, and the second one fails to be reported, the other 97 will also fail, so it does 97 requests for namespace metrics that are not going to be reported.

Remember this thread.

In any case I think this is not such a big deal, so as you prefer, but I find the possibility of handling this as an advantage of using reporter V2.

Yeah, I completely forgot about that thread. I just wanted to be sure that we were taking into account all possible scenarios. I'll modify it. Thanks Jaime 🙂