fix/resting-heart-rate-offset

[pvannierop]

Problem

On the CONNECT project we experienced problems with retrieval of Fitbit resting heart rate (RHR) data. The Fitbit connector would every day download the same RHR datum that lies far in the past.

Analysis

As far as I can see there is a problem with determining the date of the next RHR datum. RHR is queried at the resolution of a single day:

    return baseUrl + "/1/user/%s/activities/heart/date/%s/1d.json?timezone=UTC";

The existing logic will take the date of the last successful RHR datum, add one second, round this to days and use the resulting day to query the next RHR datum:

    ZonedDateTime startDate = this.getOffset(user).plus(ONE_SECOND)
        .atZone(UTC)
        .truncatedTo(SECONDS);
    return Stream.of(newRequest(user, new DateRange(startDate, ZonedDateTime.now(UTC)),
        user.getExternalUserId(), DATE_FORMAT.format(startDate)));

This will effectively result in the same day being queried over and over since this will always resolve to the same day offset of the last successfull datum.

Solution

This PR will correct the offset for the next datum by progressing the startDate with one day instead of one second.

[yatharthranjan]

Nice sleuthing. I completely overlooked this in the previous fix. Thank you!

Just a minor comment on changing the base branch to dev

[mpgxvii]

Hi @pvannierop, LGTM. Sorry I missed your Slack message but yes we did run into a similar issue with Oura because the data is pulled at daily intervals as well, and we were only adding a very small offset after every successful request. It was updated here: #147. (and later refined to use a 12-hour overlap but one day works for this Fitbit RHR case)

[pvannierop]

The Snyk test fail, but I plan to update these in a followup PR part of the March 2026 security updates.