Due to how the internet works we found that in some cases the sending of the eventList stored on the client would be marked as failed and the full eventList would be retried, while it actually succeeded the first time.
This happens when the client sends the list but before the client receives the 204 response from our server the internet connection on the client drops. For games that naturally are played by devices with a bad internet connection this was turning into a problem. Having a longer timeout period before retrying would mitigate the problem slightly but would also cause some events to never be sent. Therefore we decided to have a unique ID on each event and quite aggressively retry the sending of events (so nothing gets missed) and invalidate the events that are sent more than once (based on their unique eventUUID). The timestamp you see in the invalid events table is not the events table is the time stamp it has been received by the server, not the one attached by the client.
In short. If you record an event twice by using the sdk this will result in an event with the same parameters that could theoretically even happen at the same time but since you record it twice the SDK considers it two separate events and attaches different eventUUID values to them.