You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
sdk/metrics: dynamically created delta and cumulative async instruments use reader's previous collection timestamp instead of instrument creation time on first collection #8980
Per the Start timestamps specification, on the first collection interval for an instrument, delta aggregations and cumulative asynchronous series measured in that first interval should use the creation time of the instrument as their start timestamp.
Because RegisteredReader.lastCollectEpochNanos (RegisteredReader.java#L29-L63) is tracked per reader and only falls back to instrumentCreationEpochNanos when lastCollectEpochNanos == -1 (before the reader has performed any collection), an instrument created after the reader's first collection (instrumentCreationEpochNanos > lastCollectEpochNanos) will receive the reader's previous collection timestamp (from before the instrument existed) on its first collection instead of instrumentCreationEpochNanos.
Hi maintainers, I'd like to work on this issue if it's available for external contribution.
My proposed approach is to first add deterministic regression coverage for instruments created after a reader has already collected, then investigate the start-timestamp selection in the affected delta synchronous and asynchronous storage paths. I'd also check that subsequent collections retain the expected temporality semantics.
Would you be open to assigning this issue to me, or letting me know if someone is already working on it? I'll hold off on opening a PR until the approach is confirmed. Thanks!
Nobody is working on this yet, so feel free to open a PR! Taking Math.max of the reader's last collect timestamp and instrumentCreationEpochNanos (along with regression tests for delta sync, delta async, and cumulative async instruments created after a collection) should be sufficient.
I've opened PR #8992 implementing the suggested Math.max fix, with regression tests covering delta synchronous, delta asynchronous, and cumulative asynchronous instruments across both memory modes.
The local metrics-module checks are passing. Looking forward to your feedback!
Activity
DevyanshMalhotra commentedon Oct 28, 2026
Hi maintainers, I'd like to work on this issue if it's available for external contribution.
My proposed approach is to first add deterministic regression coverage for instruments created after a reader has already collected, then investigate the start-timestamp selection in the affected delta synchronous and asynchronous storage paths. I'd also check that subsequent collections retain the expected temporality semantics.
Would you be open to assigning this issue to me, or letting me know if someone is already working on it? I'll hold off on opening a PR until the approach is confirmed. Thanks!
dashpole commentedon Oct 30, 2026
Nobody is working on this yet, so feel free to open a PR! Taking
Math.maxof the reader's last collect timestamp andinstrumentCreationEpochNanos(along with regression tests for delta sync, delta async, and cumulative async instruments created after a collection) should be sufficient.DevyanshMalhotra commentedon Oct 31, 2026
Thanks @dashpole for the guidance!
I've opened PR #8992 implementing the suggested
Math.maxfix, with regression tests covering delta synchronous, delta asynchronous, and cumulative asynchronous instruments across both memory modes.The local metrics-module checks are passing. Looking forward to your feedback!