fix(opentelemetry-sdk): keep synchronous gauge values across cumulative collections - #5637
Conversation
…ve collections The MetricReader spec requires that for synchronous instruments with cumulative aggregation temporality, Collect receives the data points exposed in previous collections regardless of whether new measurements have been recorded: https://opentelemetry.io/docs/specs/otel/metrics/sdk/#metricreader _LastValueAggregation dropped its value on every collection, so a synchronous gauge disappeared from the export as soon as one collection interval passed without a set() call. Fixes open-telemetry#4512 Fixes open-telemetry#3971
|
|
Pull request dashboard statusWaiting on reviewers · refreshed 2026-09-08 14:20 UTC Review the latest changes. Status above doesn't look right?
|
There was a problem hiding this comment.
@open-telemetry/python-maintainers I’d consider this a non-breaking public API bug fix, although it intentionally changes the exported telemetry in a way that users may notice.
Just to provide more context to reviewers:
Behavior before this change: A synchronous gauge using cumulative temporality was exported only on the first collection after gauge.set(). If no new value was recorded, the data point disappeared from subsequent collections.
Behavior after this change: The last recorded value is retained and exported on every cumulative collection until it is replaced by another gauge.set() call. Delta temporality and asynchronous instruments (ie., observable gauge) remain unchanged.
…moryMetricReader Collecting twice through an InMemoryMetricReader without recording a new measurement in between must still export the gauge with its last value.
|
I agree with the sentiment that this is a bug/spec compliance fix and not really a breaking change. |
|
Change is good. For the Pr description, does this fully address #3971 thought? |
Well, according to description form breaking change is "fix or feature that would cause existing functionality to not work as expected", which is true or false depending on what "work as expected" means :D If we mean "as before" then it is breaking change. If "according to spec" then it's not. But the word "fix" suggests me that "as before" is proper interpretation. But anything works for me. |
Hmm, when I was searching the issues I found this one and I thought that it may be caused exactly by the same thing. What I did is just tested with the script from the issue after implementing my fix so I assumed it fixed it. But turns out it also works already on the main branch, so apparently someone fixed it before and I just falsely assumed my fix also fixed that one. I will remove it from the description, sorry for confusion. |
github-project-automation
Bot
moved this from Ready for merge
to Approved PRs
in Python PR digest
4 participants
Description
The MetricReader spec requires that for synchronous instruments with cumulative aggregation temporality, Collect receives the data points exposed in previous collections regardless of whether new measurements have been recorded:
https://opentelemetry.io/docs/specs/otel/metrics/sdk/#metricreader
_LastValueAggregation dropped its value on every collection, so a synchronous gauge disappeared from the export as soon as one collection interval passed without a set() call.
Fixes #4512
Type of change
Please delete options that are not relevant.
How Has This Been Tested?
Does This PR Require a Contrib Repo Change?
Checklist: