Fix: preserve delta start timestamp in fast path

[fmutlu68]

Fixes #4038

Changes

• Track the last delta collection timestamp in the fast path
• Use the previous collection time as the start timestamp for delta metrics

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: fmutlu68 / name: Furkan Mutlu (39f0888, c6738ce)
• ✅ login: ThomsonTan / name: Tom Tan (7e4e191)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.09%. Comparing base (90de1e1) to head (06e92a4).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4069      +/-   ##
==========================================
+ Coverage   82.09%   82.09%   +0.01%     
==========================================
  Files         385      385              
  Lines       15989    15994       +5     
==========================================
+ Hits        13124    13129       +5     
  Misses       2865     2865              

Files with missing lines	Coverage Δ
sdk/src/metrics/state/temporal_metric_storage.cc	97.73% <100.00%> (+0.14%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ThomsonTan]

On the empty-collection path, the function early-returns when delta_metrics->Size() == 0 before updating last_delta_collection_ts_. If a cycle at t2 is empty and the next cycle at t3 has data, the emitted point will carry start_ts = t1 (the last non-empty collection) rather than t2, even though the delta map only contains activity from (t2, t3]. Successive delta windows then overlap instead of abutting, which violates the OTel data model's requirement that start_ts(n) == end_ts(n-1) and causes rate computations (value / (end - start)) to under-report. The slow path doesn't have this issue because last_reported_metrics_[collector].collection_ts is updated on every call, including empty ones.

[ThomsonTan]

Thanks @fmutlu68 for the fix. Please add a unit test that calls buildMetrics for a single delta collector across at least three collection cycles (with one empty cycle in the middle) and asserts that each MetricData::start_ts equals the previous end_ts. Without it, the fast path can silently regress again.

[fmutlu68]

@ThomsonTan Thank you for your detailed feedback. I have created a unit test which contains 3 cycles which you mentioned. Could you check it ?

[lalitb]

One thing I want to double check before approving: this new slow-path update may be unreachable. Once a collector has reported, we create an entry in unreported_metrics_ for it, and later we only move present->second, we never erase the map key. So present == end() may not really happen together with reported != end(). Can you confirm whether this branch is actually expected to run?

[fmutlu68]

Could anyone have a look at here ? @ThomsonTan @lalitb It passes all checks