Only observed in the wellness-service/wellness/dailySleepData REST endpoint, but might also be found elsewhere, this is over-taxing the database engine and the network, as well as burdening interactive responsiveness. This RESTful backend is responding with increasingly larger amounts of data as you interactively visit prior days' metric data with the '<' hyperlink. What starts for a single day as about 200 KB of data grows seemingly without bound beyond 100 MB as you examine prior days. [Best summary I could come up with - see below].
From any given web page connect.garmin.com/modern/daily-summary/2024-mm-dd, click on 'View Details' in the HRV Status area. For comparison, enter the browser's developer tools area to find connect.garmin.com/wellness-service/wellness/dailySleepData REST query and observe the size of the response. For me, today, it was 234 KB.
Now click the '<' hyperlink adjacent to the 'Today' button. As expected, the browser shows the prior day's date in the address bar. Click 'View Details' in the HRV Status area again. Return to the developer tools and observe the size of the response to the new wellness-service/wellness/dailySleepData query. Click the '<' hyperlink again, and again 'View Details' for HRV Status. You can repeat those two interactive actions several times to "back up" several days before returning to developer tools to look at the size of that most recent connect.garmin.com/wellness-service/wellness/dailySleepData response. I "backed up" 30 days and the size was >166 MB. I didn't keep going to see if there was any throttle on the number of days to include in the response. I also didn't try variations like clicking the '>' to advance the date before resuming additional '<' interactions.
It appears on first blush that if you manually change the URL in the address bar to navigate to a specific date, say for example 2023-01-31, then repeatedly do the View Details and '<' interaction, the REST response size increases as before, but now ends the span of dates with 31-Jan (in this illustration) instead of continuing to the actual current date. I don't see anything in the REST query to identify that 'end' date; its like the backend is using some other source of information to know the date to which the user initially navigated.
Again, I only observed this for a single REST endpoint, but this kind of thing often reflects a coding pattern that will appear for other endpoints as well.
For completeness, I use the Chromium browser on Windows, but I doubt it being caused by the user platform.
