There are two possibilities that I see based upon the coe.

1) The isolation level that triggers this is not "REPEATABLE READ", which is the default.
2) autocommit was enabled.

PRPNet disables autocommit, but does not modify the isolation level. If incorrect the isolation level allows one transaction to read records that have been written by a second transaction before the second transaction is committed. That is very bad and definitely not the behavior PRPNet needs.

I will modify the server code to set the isolation level to "REPEATABLE READ". If this happens again, I would really need debuglevel=4 set and it would need to be set when the initial prime is found, not when the error occurs. I could also modify the code to check for the entry in the UserPrimes table before trying to insert again, but I think that is overkill as this is the first time I've seen this happen and everyone knows I put almost all of my resources on CRUS.

My recommendation is to not use PRPNet for such small numbers since you waste a lot of time in communicating with the server. My personal preference is to use pfgw with the number_primes option until the test take more than a few seconds a piece.

I realize that you end up wasting time using prpnet starting that low. The bulk of the work though is slow enough that it isn't an issue. I find it easier to skip a step by going straight to prpnet especially as prpnet/pfgw use very little cpu power while the tests are that small so I can run something else as well.

Even though I will make this change AND even though I will add some error checking to output a message if these settings cannot be changed by the application, it is still possible that MySQL has a bug that caused the problem. I can't prove that, but evidence points in that direction.