[cups] Why do filter failures stop jobs instead of aborting them?

[hw]

Bryan Mason wrote:
> On Fri, 2017-08-11 at 20:13 +0200, hw wrote:
>> Bryan Mason wrote:
>>> The definition of the "processing-stopped" state in RFC 2199 says
>>> that jobs in the "stopped" state will resume processing as soon as
>>> the reasons for the stoppage are no longer present.  This seems to
>>> imply that "processing-stopped" is a temporary state that will
>>> correct itself.
>>
>> Any state can only be considered as temporary after it has been
>> changed.
>>
>> When a printer is out of paper or experiences a paper jam, it´s in a
>> state that doesn´t correct itself.
>
> True, but in my experience, the job state for that sort of error is
> either "processing" because the backend is retrying the connection to
> the printer, or "aborted" or "pending" (depending on the value of the
> printer-error-policy) because the backend has exited with an error.
>
>>> Most of the filter failures that I've seen are caused by a missing
>>> file (hpijs/foomatic/etc.), by a bug in one of the filters, or by a
>>> malformed input file (bad PDF, etc.).  All of these require some
>>> sort of corrective action and you need to resubmit the print job
>>> after the problem is corrected.
>>>
>>> To me, setting the state to "aborted" when a filter fails seems to
>>> make more sense.  I admit that I'm probably looking at this through
>>> a pretty narrow lens right now, so I understand if there are
>>> broader reasons for not doing this.
>>
>> If the job was aborted, the user at the client might figure that
>> they should resubmit the job, which would be rather pointless but
>> consume resources.
>
> That's possible, although it's been my experience that user eventually
> complains to their IT group who fixes the problem.  In the meantime,
> the job with the problem is stopping all the other users' jobs from
> being processed (it's a shared applications server).

Cups is weird with error handling anyway.  Sometimes jobs become halted,
and to get the printer to print them, you need to release every single
job manually.  Sometimes it helps to pause the printer and then resume
it, but not every time.  I also keep wondering what the difference in
the default settings is between 'retry job' and 'retry current job'.
When a job is being retried, it is the current job --- or how else
could a job be retried at all.

And who would want to stop a printer when a job can´t be printed?  That´s
a very bad default.