I think this may be an incorrect assumption, but I'll still say it.Right, because lots of other projects with overcrowded servers would be affected by such a race condition. Though maybe Cosmology@Home has some own file shuffling going on in the background, such that they introduce a race condition of their own.
Projects with high volumes of connections/tasks tend to use RAM disks to temporarily store incoming data results. And because C@H use a quorum of 1, the task gets added to the validator queue to be validated immediately. Which is what I am assuming is happening to some of my tasks that get submitted, is that the validator doesn't wait for the file handler to move it from RAM disk to storage. This wouldn't be a problem if the invalid:valid ratio is low. But 35% is way too much
That is the basis I think they are creating their own race condition, in that they have quorum of 1, where most other projects I know have 2 or more. Such as PG or S@H.
EDIT: I may have found a config tag which specifies the delay between the scheduler declaring the task as finished and the validator running. And I think C@H have set that to 0. Meaning as soon as your scheduler request goes through it tries to validate