Flaky test: `ClockTest.userTimeClock`

[joschi]

ClockTest.userTimeClock has been failing regularly in recent builds:

Error:  Failures: 
Error:    ClockTest.userTimeClock:19 
Expecting actual:
  8.9793854284E10
to be close to:
  8.9794920593E10
by less than 1000000.0 but difference was 1066309.0.
(a difference of exactly 1000000.0 being considered valid)
[INFO] 
Error:  Tests run: 319, Failures: 1, Errors: 0, Skipped: 0

https://github.com/dropwizard/metrics/blob/af5cfc03261e2bbecd9c04c63b3d99d3ecaf1ce0/metrics-core/src/test/java/com/codahale/metrics/ClockTest.java#L10-L21

[baharclerode]

Clock.getTick() returns a long, but it's being cast to a floating point value:

(double) clock.getTick()

Is this possibly causing precision issues?

A widening conversion of an int or a long value to float, or of a long value to double, may result in loss of precision - that is, the result may lose some of the least significant bits of the value. In this case, the resulting floating-point value will be a correctly rounded version of the integer value, using IEEE 754 round-to-nearest mode

Also, 1,000,000 nanoseconds is just 1 millisecond. Is there a reason the assert for getTick() has such a tighter bound on variance than getTime()? I would expect the allowed variance for both to be the same.

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. Remove the "stale" label or comment or this will be closed in 14 days.