? Don't know if the servers do, but the client has to be talking to the server first and the job not yet started. If started it becomes a race condition. Will the "No Reply" client or the "Make Up" client return the result first. If former still returns before latter, credit is granted. If latter is quicker, former gets nop.

Auto-Abort depends also on the client version. Prior to 5.10 the user gets a message with a recommendation to abort the unit given it's overdue.

I suppose it could be done, if not already, but the few who do return a late job would/could trow up due an error in their Result Status page. If they still do they get a "Too Late" in the RS Status log.... a good hint to reduce the buffer size as "repeated" make up jobs due a late reporting by the same client does impact storage efficiency holding up the whole batch.

And again, it depends if a client talks to the server during the crunch. Multi project crunchers with a low weight on WCG likely will not call for a new job, just report when done.... too late for an abort transmission. All in all a very minor gain not worth breaking the code for is my guesstimation. After my writing Murphy comes by and the Tech sharing that it is a 0.1% impact.... which would be worth asking the Berkeley developers to add code to the server software.... internal stats would reveal that.