Well ok, i have not much more ideas about the cause for now. I need the client log to see what is happening as you recommending. Thanks.
Is this something that happens consistently or is it only happening for certain users or is it intermittent?
In more than 10000 revisions for all questionnaires we have 4 cases of duplicate revisions. But how in one revision we can have more than one case we end up having about 25 false positive duplicate interviews.
I created a report to measure when we ended up having in the queryable tables a different revision than the revision that is present in CSWeb for the same guid and caseid. This happens exactly in the case where we received more than one revision for a finished case, as we only save in the queryable tables the first finished and not deleted case that we received form the same caseid. This is because we don't allow duplicate cases in the queryable tables and also don't allow override a case without to have authorization.
That could conceivably be something like my network failure/retry idea. I imagine that it will be hard to verify this given how infrequently it happens.
I spent some time this morning trying to reproduce it myself by hitting ctrl+shift+s over and over again to sync the same case but I was not able to reproduce the issue. I get the additional rows in cspro_sync_history but the revisions number for the case in the other table do not change.
Maybe you could implement de-bouncing on your end. Don't send an email about a case if you previously sent email less than XX seconds ago.
Yes, it look like you have right in your assumption. The survey is taking place in a aleatory sample of all Mexico. So, it's a fact the in some places the interviewer will have not a good connectivity.
Maybe you could implement de-bouncing on your end. Don't send an email about a case if you previously sent email less than XX seconds ago.
Yes that will work to prevent the problem, but it is at the same time to accept that we can leave out cases that are really a positive change and not a false one. In addition, take x seconds in account is also an assumption, but yes is a thing to take on account from our side thanks.