What this PR does / why we need it:
A community member followed a tutorial for setting up Twinmaker that had timestamp in unix time. They were getting duplicated results due to the plugin sending time string to GetPropertyValueHistory in string with only second precision.
When we query streaming, we set the startTime to the latest timestamp of the previous set of results. The startTime we were sending was always set to second + 0 milliseconds (second precision): timeObject.Format(time.RFC3339), so it would always actually query before the last timestamp.
For example, our last entry was at 2024-01-08T19:58:34.123+01:00. The util function was parsing it into 2024-01-08T19:58:34+01:00, losing the milliseconds.
When parsed into unix millisecond timestamp, the original last entry is at 1704740314123, but ours ends up being 1704740314000, before that. This is why the lambda always returns the last entry.
What this PR does / why we need it: A community member followed a tutorial for setting up Twinmaker that had timestamp in unix time. They were getting duplicated results due to the plugin sending time string to GetPropertyValueHistory in string with only second precision.
When we query streaming, we set the startTime to the latest timestamp of the previous set of results. The startTime we were sending was always set to second + 0 milliseconds (second precision):
timeObject.Format(time.RFC3339), so it would always actually query before the last timestamp. For example, our last entry was at2024-01-08T19:58:34.123+01:00. The util function was parsing it into2024-01-08T19:58:34+01:00, losing the milliseconds. When parsed into unix millisecond timestamp, the original last entry is at 1704740314123, but ours ends up being 1704740314000, before that. This is why the lambda always returns the last entry.Which issue(s) this PR fixes:
Fixes https://github.com/grafana/grafana-iot-twinmaker-app/issues/263
Special notes for your reviewer: