Stagger timestamps in exact aggregator tests

[punya]

Fixes #1559.

[Aneurysm9]

I could swear I tried this while I was trying to debug these tests and it didn't work, but this is definitely working now. I am, however, still seeing errors in the TestMergeBehavior test:

--- FAIL: TestMergeBehavior (0.00s)
    --- FAIL: TestMergeBehavior/Int64Kind (0.00s)
        --- FAIL: TestMergeBehavior/Int64Kind/Forward=false (0.00s)
            exact_test.go:347: 
                        Error Trace:    exact_test.go:347
                        Error:          Should be true
                        Test:           TestMergeBehavior/Int64Kind/Forward=false
        --- FAIL: TestMergeBehavior/Int64Kind/Forward=true (0.00s)
            exact_test.go:347: 
                        Error Trace:    exact_test.go:347
                        Error:          Should be true
                        Test:           TestMergeBehavior/Int64Kind/Forward=true
    --- FAIL: TestMergeBehavior/Float64Kind (0.00s)
        --- FAIL: TestMergeBehavior/Float64Kind/Forward=false (0.00s)
            exact_test.go:347: 
                        Error Trace:    exact_test.go:347
                        Error:          Should be true
                        Test:           TestMergeBehavior/Float64Kind/Forward=false
        --- FAIL: TestMergeBehavior/Float64Kind/Forward=true (0.00s)
            exact_test.go:347: 
                        Error Trace:    exact_test.go:347
                        Error:          Should be true
                        Test:           TestMergeBehavior/Float64Kind/Forward=true
FAIL
FAIL    go.opentelemetry.io/otel/sdk/metric/aggregator/exact    0.038s

These can be addressed by inverting the ordering check in that test as was done earlier in the other tests in that file:

diff --git a/sdk/metric/aggregator/exact/exact_test.go b/sdk/metric/aggregator/exact/exact_test.go
index 10e0c615..0a8f1cb4 100644
--- a/sdk/metric/aggregator/exact/exact_test.go
+++ b/sdk/metric/aggregator/exact/exact_test.go
@@ -344,7 +344,7 @@ func TestMergeBehavior(t *testing.T) {
                                        received.Append(s.Number)
 
                                        if i > 0 {
-                                               require.True(t, pts[i-1].Time.Before(pts[i].Time))
+                                               require.False(t, pts[i-1].Time.After(pts[i].Time))
                                        }
                                }

It may be worthwhile to put the sleeps into that test as well since it does the same ordered contents check that was flaking in the other test.

[punya]

Thanks for the catch @Aneurysm9! Do you think it's better to use sleep across the board and revert the relaxed time comparisons (which should be unnecessary once the timestamps are guaranteed to be distinct)?

[Aneurysm9]

I think perhaps we should keep both the sleep and the not-after check. The sleep helps ensure that the same order test is unambiguous and the not-after check validates what the code actually does. I think the implementation would need to change if we wanted to ensure that the points from checkpoint 1 always ended up first in a merged checkpoint when points from both checkpoints were recorded at the same instant.

[codecov]

Codecov Report

Merging #1569 (ef1afd2) into main (b94cd4b) will decrease coverage by 0.2%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##            main   #1569     +/-   ##
=======================================
- Coverage   78.2%   78.0%   -0.3%     
=======================================
  Files        127     127             
  Lines       6577    6597     +20     
=======================================
+ Hits        5149    5151      +2     
- Misses      1183    1201     +18     
  Partials     245     245             

Impacted Files	Coverage Δ
attribute/type_string.go	10.0% <0.0%> (-23.4%)	⬇️
metric/instrumentkind_string.go	10.0% <0.0%> (-23.4%)	⬇️
metric/number/kind_string.go	16.6% <0.0%> (-16.7%)	⬇️
sdk/export/metric/exportkind_string.go	0.0% <0.0%> (ø)
exporters/otlp/otlpgrpc/connection.go	88.7% <0.0%> (+1.8%)	⬆️