refactor stat_item: report only changed values
Change the functionality of skipping unchanged values: instead of
looking up whether new values have been set on a stat item, rather
remember the last reported value and skip reporting identical values.
stats_test.c shows that previously, a stat item reported a value of 10
again, even though the previous report had already sent a value of 10.
That's just because the value 10 was explicitly set again, internally.
From a perspective of preserving all data points, it could make sense to
send consecutive identical values. But since we already collapse all
data points per reporting period into a max, that is pointless.
Related: SYS#5542
Change-Id: I8f4cf34dfed17e0879716fa2cbeee137c158978b
diff --git a/src/stats.c b/src/stats.c
index 5dac242..28a3ab3 100644
--- a/src/stats.c
+++ b/src/stats.c
@@ -700,15 +700,11 @@
if (!srep->running)
continue;
- /* If no new stat values have been set in the current reporting period, skip resending the value.
- * However, if the previously sent value is not the same as the current value, then do send the changed
- * value (while n == 0, the last value from the previous reporting period is in item->value.max == .last
- * == .min, which was put in new_value above).
- * Also if the stats reporter is set to resend all values, also do resend the current value regardless
- * of repetitions.
+ /* If the previously reported value is the same as the current value, skip resending the value.
+ * However, if the stats reporter is set to resend all values, do resend the current value regardless of
+ * repetitions.
*/
- if ((!item->value.n && new_value == prev_reported_value)
- && !srep->force_single_flush)
+ if (new_value == prev_reported_value && !srep->force_single_flush)
continue;
if (!osmo_stats_reporter_check_config(srep,