These never cease to amaze me. I must have gotten this WU after its deadline passed for the one wingman, then it validated for them, then I finished the WU and now I am awaiting validation. Will it ever validate for me?
WU: http://setiathome.berkeley.edu/workunit.php?wuid=965242964

---

SETI@home classic workunits 4,019
SETI@home classic CPU time 34,348 hours

These never cease to amaze me. I must have gotten this WU after its deadline passed for the one wingman, then it validated for them, then I finished the WU and now I am awaiting validation. Will it ever validate for me?
WU: http://setiathome.berkeley.edu/workunit.php?wuid=965242964

There are about 12000 AP v5s in that situation. I have 4 of them. It seems to be a result of a server code change made around August last year. However, this is the first AP v6 example that I am aware of.

---

I have 1 myself, http://setiathome.berkeley.edu/workunit.php?wuid=953687194, but neither has passed its' report deadline yet so I'll find out on the 9th and you'll find out on the 25th to see if they clear the database (or will v6 suffer the same v505 problem?).

Cheers.

---

These never cease to amaze me. I must have gotten this WU after its deadline passed for the one wingman, then it validated for them, then I finished the WU and now I am awaiting validation. Will it ever validate for me?
WU: http://setiathome.berkeley.edu/workunit.php?wuid=965242964

I have several.

As has been noted, the problem appears to be triggered when one computer fails to meet the assigned deadline but manages to report the result before the assigned replacement reports its result.

The right thing to do would be to not accept work units past their deadline except when the system is overridden during known extended outages but under that condition the system would be down so few, if any, additional work units would be generated or distributed so this problem would rarely occur. Don’t know if it is still present but unnecessary work units used to be deleted so just change the condition for triggering the deletion to be overdue.

The previous version of this bug used to deny credit and validation to the computer that completed its work on time and instead validate the result from the delinquent computer including assignment of associated credit. This also means that canonical result may not be assigned to the best analysis as that result may be the one that is being ignored. This version of the bug just leaves us in limbo with the same net of no validation and no credit.

---