Closed MilosKozak closed 11 months ago
nevermind i probably found it: record's date > srvModified
but question is if it's expected behavior.
current implementation in AAPS is that if I get non empty result I continue quering (expecting there could be more records) with the timestamp of etag: W/"1694958729909"
which holds largest srvModified
in returned set.
In this case it leads to endless loop
Thinking of the logic it should be based only on srvModified
https://github.com/nightscout/cgm-remote-monitor/blob/master/lib/api3/generic/history/operation.js#L106
... and using srvModified
which is based on server's clock and timestamps in records (based on client's clock) in one query can lead to other potential errors
Should it be possible to use created_at
instead? Does everything through /api/v1
get srvModified
? I don't think that happens, although it could.
srvModified
nad srvCreated
is populated only through v3
maybe that's the reason why date
and created_at
is here https://github.com/nightscout/cgm-remote-monitor/blob/master/lib/api3/generic/history/operation.js#L106
but generally it breaks the logic of sync with v3
I'd recommend keep only srvModified
. I declared in release notes to use only v3 for upload once you turn it on in AAPS
I hope v1 will be removed or adapted in the future
https://github.com/nightscout/cgm-remote-monitor/pull/8100 with this patch sync stuck no more
With #8100 merged, I guess this issue can be closed.
Sometimes happen this:
ie querying records with
srvModified > 1694958729909
but as you see record withsrvModified==1694958729909
is returned