Update: It happened again. This time with a fairly good internet connection, so it may not be related after all. Perhaps it’s a server-side thing rather than a client-side issue?
i would think you would need a relatively fast connection for this to occur. once you click agree or disagree on a particular annotation, the screen will prevent you from clicking agree or disagree again on that particular annotation until the observation has been updated. however, you can click agree or disagree on multiple annotations, and each of these will trigger a separate request which upon completion (of any of the requests) will trigger your screen to update the observation.
this means that the last request could still be processing when the first request is completed. and when that happens, your observation will be updated to show that the first annotation now has an agreement or dsagreement but the last annotation does not. at this point, it will be possible to send a second request for the last annotation, and if that second request on the last annotation is received before the first request on the last annotation is still being processed, then that’s probably when you end up with the double agree or disagree.
below are the datetimestamps of your votes on this latest example:
Annotation
Value
Vote Datetimestamp
Evidence of Presence
Organism
2024-11-02 08:42:52.534Z
Alive or Dead
Alive
2024-11-02 08:42:52.806Z
Alive or Dead
Alive
2024-11-02 08:42:52.914Z
Life Stage
Adult
2024-11-02 08:42:54.086Z
you can see that your votes are getting processed in relatively quick succession. probably you clicked agree to Alive, then Organism, but the Organism agreement processed first, resulting in the opportunity for you to click agree to Alive again.
…
although there is a mechanism here that allows you to double vote in some cases, i sort of think the problem is so minor and unusual that it may not be worth addressing.
i’m not sure exactly how the system processes these votes, but i’m guessing the fix would probably involve some sort of validation or other mechansim to prevent the same user from making the same kind of vote twice at a database level. (i think the system is probably already checking during processing to make sure the observation at the start of processing a request doesn’t already have a vote from that user, but if you have two concurrent requests for the same kind of vote from the same user, then this kind of check may not work reliably, if it’s not also locking down the observation.) however, that kind of validation has negative implications for the ability of the system to process a lot of stuff at the same time.
an alternative solution would be to change the observation / identfication screens to update the observation only after all the pending requests are completed. but that comes with downsides as well.
This is not new either. I have seen this happen on my own observations a handful of times over the course of probably 2 years. Never reported because I’m lazy…
