* Lee Howard <faxguy@xxxxxxxxxxxxxxxx> [070222 15:08]:
I wouldn't characterize my approach as "blind". When we get to a
job.remove() and the job is not on a list we have two options: skip the
job.remove and deal with the consequences or die with the assert error.
I realize your approach isn't "blind" in that sense. But your not
dealing with the consequences. You're choosing to just accept the fact
it's not on a list and skip handling it.
The real problem came earlier - we shouldn't even be considering a
job.remove if the job isn't on a list in the first place. However, the
asynchronicity makes faxq rather difficult to debug on rare timing
issues like this.
But if the job isn't on a list, it *should* have been. That *is* the
real problem. There are very few instances when a job shouldn't be on
a list, and those instances are (or at least should be) in known
transition points.
If there's a problem with faxq, I'm interested in seeing it, and I want
to get to the bottom of it. faxq *should* be rock solid, without
papering over bugs.