When I first set up the sensor it kept firing off the same event every polling iteration. It didn't seem to be respecting the last id.
It looks like GitHub posted two events at the same time (exactly per the timestamp). This packs GitHub sensor is assuming the last item in the list will always have the highest (numerical) id.
if last_event_id and int(event.id) <= int(last_event_id):
But because these two events have the exact same date stamp, the GitHub api doesn't reliably return the results in numerical order. In my case, the last item in the list which the sensor marks is the last id self._set_last_id(name=name, last_id=events[-1].id) was actually smaller in numeric id, the the one the one before it.
An easy fix is to first sort the list of results by event.id before handling it since the rest of the logic is assuming highest id == last event.
A more permanent and breaking fix would be to use the actual timestamp value instead of id when determining the latest event.
When I first set up the sensor it kept firing off the same event every polling iteration. It didn't seem to be respecting the last id.
It looks like GitHub posted two events at the same time (exactly per the timestamp). This packs GitHub sensor is assuming the last item in the list will always have the highest (numerical) id.
But because these two events have the exact same date stamp, the GitHub api doesn't reliably return the results in numerical order. In my case, the last item in the list which the sensor marks is the last id
self._set_last_id(name=name, last_id=events[-1].id)was actually smaller in numeric id, the the one the one before it.An easy fix is to first sort the list of results by
event.idbefore handling it since the rest of the logic is assuminghighest id == last event.A more permanent and breaking fix would be to use the actual timestamp value instead of id when determining the latest event.