| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
There was a problem hiding this comment.
Thank you for the contribution. This looks great!
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM, thank you for the help!
Sorry, something went wrong.
System.currentTimeMillis() is a wall-clock value and is subject to NTP adjustments and DST transitions. For long-running cron jobs this can produce incorrect or even negative durations in the check-in payload. Switch the start/end capture in CheckInUtils.withCheckIn() and the three SentryCheckInAdvice implementations (sentry-spring, sentry-spring-jakarta, sentry-spring-7) to System.nanoTime(), which is guaranteed monotonic. Use DateUtils.nanosToSeconds() (already present) to convert the delta. Fixes getsentry#5579
| Back | FazBrowse Home | New Git URL |
Fixes #5579
Problem
Cron check-in durations were computed by subtracting two System.currentTimeMillis() values. The wall clock is not monotonic — it is subject to NTP steps, leap-second smearing, and DST transitions. For long-running cron jobs this gives wide exposure to clock jumps, which can produce incorrect or negative duration values in the check-in payload.
Fix
Switch the start/end capture to System.nanoTime(), which is guaranteed monotonic and is the correct choice for measuring elapsed time. DateUtils.nanosToSeconds() (already present in the SDK) is used to convert the nanosecond delta to the seconds value expected by setDuration().
Changed files:
Existing duration tests (assertNotNull(doneCheckIn.duration)) continue to pass unchanged; the delta of two nanoTime() calls is always non-negative and non-zero for any real workload