Good point. I did not put the counter increase in the error handling functions, because it is only retried after the next connect, which happens after time-reopen, which is 1 minute by default. So we increase the counter 1 minute earlier, but maybe we can live with that. What do you think?

I think we can live with that :)

Moved it to the result handling functions and it happened to end up around rewind_batch(), which is a good indication that it is in the correct place. :) Thanks for the suggestion.

Thank you. A last question: can't we actually put this into rewind_batch()? I see that every call of that function precedes the metric update. rewind_batch() is the most direct way of saying "we will retry this" in my opinion, so probably the metric belongs there and it would remain correct even if we introduced more error paths.

To me it felt a bit side-effecty. If we put it there, I feel like we should rename the function. I will try to come up with something, and if I cannot find, I will just put the stats increase there and not rename it.

@MrAnno Could not come up with a better name :)

I don't think we need a better name, recording metrics are normal side-effects.