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

[Bryan Mason]

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).

~ Bryan