Comment 17 from @bernard_hiller perhaps also applies to these unwanted duplicates.
To me, it looks more like a “race condition”. The web site is “multi-threaded”. A request gets sent to the server, and while the browser is waiting for the reply, you’re clicking different things and thus send further requests, and somewhen the replies come back to your browser, but not in the order you would need them. From a software developer’s point of view, quite the naughtiest thing you could have to try to fix. Because everytime you try to repeat the issue, a little different timig is required, and reproduction fails… And of course, it does also depend on the JavaScript implementation of your browser. Infinite number of combinations possible.
A frequent error I have encountered is when a user withdraws an ID and then places a new ID on an observation that is identical to the previous one. I know this happens mostly because of lags when a user is identifying in the app and sometimes also on the website, and it is not because this person does it intentionally. Still, it is annoying to have a long series of unnecessary retracted IDs on your observations. See this link for an example of this unintentional error, where a user accidentally duplicated the same ID eight times, out of which seven are withdrawn: https://www.inaturalist.org/observations/349999008.
This issue has already been adressed in a topic in September 2019 (see: https://forum.inaturalist.org/t/prevent-duplicate-identifications/6498) but the error still ocurrs, so it seems nothing has been done to prevent it. Is it possible to code the identification process in the app/website in such a way that an observer can only place the same (withdrawn) ID once?
I agree that not allowing an additional identical ID might be good, though only if the ID contains no comment. Sometimes a user might add a comment to the second ID or similar and that shouldn’t be lost.
The question becomes: What is the cause of the delay in ID confirmation/posting? This type of situation most often occurs at the intersection of a slow internet response and some impatience on the part of the IDer/uploader. Even if there is an automated response akin to, “You have already added this ID to this observation,” the slow internet response may still prompt an impatient person try and repost. That is, the warning of a duplicate ID would probably show up no sooner than the posting of the first (or subsequent) IDs. Patience…and screen refreshing…are probably the best solutions.
It doesn’t only happen with slow internet or user impatience. I’ve seen it happen not infrequently when I have added an ID once, but when the page refreshes I am shown as having added the same ID twice (and withdrawn the first one). I haven’t noticed any pattern to when it happens.
Appreciate the comment, but no, that is not what the question becomes and neither the point of this post. We already know that a lag in internet connection causes the problem. We have known that at least since the post I referred to from September 2019 but six-and-a-half years later we still have the same problem. Patience and screen refreshing do not solve the problem. What we need is a built-in solution within the app and website that would simply prevent a double, void, withdrawn ID from happening.
I agree - I didn’t see the request as showing a warning for a duplicate ID - just a proposal to not add an additional equivalent ID at all (ie, to reject the duplicate ID programmatically like IF ID is duplicate of previous ID by same user, drop; ELSE post ID).
Edit: I unmarked this as the solution because we only use solutions for Bug Reports that are addressed in iNat. More broadly, this could probably be considered for a feature request as well. It depends on how staff view the behavior here (as a Bug or not). I think the proposed solution could be an acceptable feature request if this is determined to not be a bug.
Agree with you again. I had actually wanted to comment that I initially hesitated where to post this because it has overlap between a bug report and feature request (i.e. we need a new ‘‘feature’’ that solves a ‘‘bug’’) but I did not want no make my post unnecessarily long either. The reason I marked your comment as a solution is because I think you have put it clearly: we need a code that would "“reject the duplicate ID programmatically like IF ID is duplicate of previous ID by same user, drop; ELSE post ID” to which following your previous reply should be added “IF ID contains no comment (=void)”.
In my experience on the web you have have the same observation showing twice in results. Seems to do it less often now, but I’m sure I had it happen in the last 2 weeks. Basically I will scan the results and ctrl-click any items of interest so they open in new tabs, perhaps 20 tabs, typically all of the same species, perhaps with a specific note in the clipboard to paste for them if I’m tackling a specific issue. If this is done twice for the same observation, either because it was twice in the results OR due to being distracted OR because you swept back and forth across the results (maybe more than 1 page) picking the ones of interest and managed to ctrl-click open an observation a second time as a second tab, then when you go through them and ID them you may end up entering the same ID twice (i.e. on different tabs), but on the second one it will have already been ID’d, it just won’t be showing, so you enter an ID that when submitted withdraws the one submitted from an earlier tab.
In upshot though, I agree with the idea, that an ID shouldn’t withdraw an identical ID. If there’s a comment on the new but repeated ID perhaps it should just post the comment without an ID, unless perhaps if the prior ID was by someone else and your identical ID was before that (unlikely in the scenario I’ve outlined), and ideally not even the comment if the prior ID has the same comment (a comment without ID can anyway be fully deleted by the submitter either way).
Sometimes i put in an ID on the website and then the website freezes iddle and nothing is happening. The only thing that seems to help is putting the same ID in again a minute later. So please, i understand that iNat’s server can be overloaded. But don’t make it worse by yet another process and rule.
Maybe related, maybe is separate issue, but yesterday I was ID’ing submissions and was working for about a half hour with no problem. Then when I hit save on a post it was taking a very long time to load, so I walked away to let it spin at its leisure. when I returned with more coffee it had finally stopped loading, but it showed that I had deleted an ID and immediately resubmitted that identical ID. I did not. After that the system seemed slow and I did a few more and moved on with my day.
Just sayin’ that there may be something else going on.
Since the staff are already aware of the issue, I went ahead and moved this discussion to the other topic to keep everything in one place. Please continue to share your experiences.
For example, recently I have encountered another apparent situation that seems to cause unintended duplicates, and it’s all on the user end. I have a keyboard that is slowly dying and often generates double keystrokes when I hit a key too hard. Sometimes this happens with the final keystroke from entering an ID, and two IDs show up, one withdrawn.
Still, though, it would be nice if iNat could be coded to ignore and/or automatically back out any such duplicates received, as long as they are truly identical (including comments if any).