Fix Health Connect "startTime must be before endTime" crash at day boundary#1
Conversation
Agent-Logs-Url: https://github.com/air17/steps_notifier/sessions/69f12ae2-6668-4ccf-acf7-d2d0d6ec3d2c Co-authored-by: air17 <18901596+air17@users.noreply.github.com>
Agent-Logs-Url: https://github.com/air17/steps_notifier/sessions/69f12ae2-6668-4ccf-acf7-d2d0d6ec3d2c Co-authored-by: air17 <18901596+air17@users.noreply.github.com>
|
@copilot can you check if this fixes the error Error: startTime must be before endTime. And if something else is necessary to do |
Yes, the fix fully addresses the Root cause: The original What the fix does (lines 166–172):
Every |
There was a problem hiding this comment.
Pull request overview
Fixes a Health Connect crash at the day boundary by ensuring todayRange() always returns a strictly non-empty time window derived from a single clock snapshot, preventing TimeRangeFilter.between(start, end) from receiving an invalid interval.
Changes:
- Compute
startOfDayfrom a singleInstant.now()snapshot (avoids theLocalDate.now()/Instant.now()race). - Guarantee
endTime > startOfDayvia an end-bound clamp (maxOf(now, startOfDay.plusSeconds(1))).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Two independent time reads in
todayRange()created a race whereLocalDate.now()could tick to the next day whileInstant.now()still held a timestamp from the previous millisecond, makingstartOfDay > nowand causing every Health Connect query to fail.startOfDayfrom oneInstant.now()call instead of two separate time readsmaxOf(now, startOfDay.plusSeconds(1))to guarantee a strictly non-empty interval regardless of clock skew or DST transitions