Hello!

Some team mates and me ran into an interesting problem with the "Aborted by user"-state.
Cause for this was this PrimeGrid-WU here.
With too many error results my team mate couldn't get credits for his finished part because of the quorum 2.
Here is a graphic list of that:



Unfortunately I'm not aware, what really counts as client error, but obviously the "Aborted by user" does.

Now our thinking was:
If the state "aborted by user" wasn't counted as client error, the server could have given out this WU some more times to make it eventually successfully finished!

So, is it possible to change the code in a way, that this state isn't counted as error result?

Edit:
Oh, there was a change at PrimeGrid right at this moment, the max. error result was increased, so my team mate gets a chance for the credits again. ;)
But my question still stays.

The problem is the max # of error/total/success tasks.

As set in your graphic the server can generate up to 15 tasks from the workunit, but as soon as 6 have been reported with errors the workunit goes to the 'Too many error results' invalid state. Any unsent tasks will be cancelled and no more tasks will be created. If the quorum hasn't been met credit won't be granted to any successfully completed tasks (even if it seems that the quorum is eventually met by an over-deadline 'No reply' task reporting a successful completion).

The modified setting of 15,15,5 will prevent this from happening (unless the workunit gets to a state when it would have generated a 16th task, in which case it will go to the 'Too many total results' invalid state).

---

"The ultimate test of a moral society is the kind of world that it leaves to its children." - Dietrich Bonhoeffer

The problem is the max # of error/total/success tasks.

As set in your graphic the server can generate up to 15 tasks from the workunit, but as soon as 6 have been reported with errors the workunit goes to the 'Too many error results' invalid state. Any unsent tasks will be cancelled and no more tasks will be created. If the quorum hasn't been met credit won't be granted to any successfully completed tasks (even if it seems that the quorum is eventually met by an over-deadline 'No reply' task reporting a successful completion).

Yes, that's clear.
In my eyes the 5/15/5 setting is a bit "harsh" if WUs like PrimeGrid LLRs oder other WU-tasks are too long that users willingly cancel them.
As fortunately happened, my team mate now has a chance to get the credits because the setting was changed to 15/15/5.
But consider it wouldn't be the case because no one did noticed respective changed it. And I wouldn't wonder much, if that wouldn't be the case.
For such cases it would be best when the "aborted by user" state isn't counted as client error. Then the server could give the WU out some times more.
I am aware about the case that "aborted by user" is also treated as a reason for reducing the daily quota. Couldn't that someone combined?