There's an old [repeated] request to give repair tasks at least the same deadline as the original, with a minimum of 4, but here goes: The repairs get the same short deadline as the No Reply, 40% of the original deadline so when 10 days, the deadline for the collective make-up jobs is 4 days. In the case of HCC that have an original deadline of 7 days, the make-up tasks deadline is 2.8 days. At the time the request was made the "same deadline as the original" required a database access to find out what that original period was, which increases database load. Since these "repair" assignments are only made to devices that are known to return work on average within 48 hours, it really makes no difference... 4 or 7 or 9 [if e.g. the error occurred on the first day the original was assigned]... these jobs get near dead sure reported withing 48 hours.

Edit: To sum it up, if reliable machines that get repair jobs, exclusively, are known to return work in 2 days, what does it matter whether that repair deadline is not one that matches the original deadline when further out than 2.8 or 4 days? Nothing, is of course the answer, so I think we can leave it at the KISS level, not load the database, and flatly take the 40% fraction of the standard return time requirement (which used to be 25%).

Edit2: The only benefit I could see from a client perspective is that it is less likely to break out of the FIFO order of processing, when the work buffer is higher than normal... in the 1.5-2 day range [Just not high enough to throw a client out of the coveted "reliable host" classification]. But who cares... BOINC is doing the work with only one mission: Deliver all tasks results before deadline.