Race condition between Update() and TakeSnapshot() can produce spurious zero data point for delta temporality

[cijothomas]

There is a known race condition between Update() and TakeSnapshot() in MetricPoint that has been documented in code since Nov 2021 (current location). Creating this issue to track it formally.

The race

Update() and TakeSnapshot() operate on two separate fields — the aggregator value and MetricPointStatus — which cannot be atomically updated together. If Update() writes the value, TakeSnapshot() reads it and resets status to NoCollectPending, then Update() sets status to CollectPending — the next cycle sees CollectPending with a zero/reset aggregator and exports a spurious empty data point.

For Counter/Histogram this is benign (zero delta adds nothing). For Gauge, value=0 is semantically meaningful and could be misleading. When this was originally accepted, sync Gauge did not exist in the spec.

The race window is nanoseconds wide and this has been in production for 4+ years without issues. Tracking here for formal acknowledgment.

References

• Original PR + code comment: Delta exporters will Export only those points which received new update #2629 (reviewed/acknowledged by @reyang)
• Same pattern in opentelemetry-rust

[cijothomas]

Found this while working on OTel Rust metrics! Had to dig up old history, but it was worth it - addition of Sync.Gauge to the spec made this bit more serious. However, I don't think there is an easy fix - 2 atomic operations are atomic on its own, but not together. Making them atomic-together would require expensive locking mechanisms, and that'll likely nullify all the perf optimizations we have done!