Ambiguity in how JobRetryInterval and retry-current-job relates

[l1gi]

Describe the bug
cupsd.conf man page says:

ErrorPolicy retry-current-job
  Specifies that a failed print job should be retried immediately unless otherwise specified for
  the printer.
...
JobRetryInterval seconds
  Specifies the interval between retries of jobs in seconds.  This  is  typically  used  for  fax
  queues  but  can  also  be  used  with normal print queues whose error policy is "retry-job" or
  "retry-current-job".  The default is "30".

Should retry of a failed job be done immediately after the fail there seems to be unclear relation to JobRetryInterval.

Expected behavior
Could you better describe what is the behavior with retry-current-job policy? Will all the attempts to retry happen as soon as possible in sequence or the first attempt will be made immediately while the rest of them with the JobRetryInterval delay between them?

[zdohnal]

Hi @l1gi ,

thanks for the report!

I have checked the code and it looks like retry-current-job is always done asap if the job failed, and JobRetryInterval delay is applied only to retry-job if the job fails or the backend returns RETRY. Is this the expected behavior, @michaelrsweet ?

[michaelrsweet]

@zdohnal Yes, that is the expected behavior.

[zdohnal]

@michaelrsweet thank you! Then is it there a way how to influence the retry-current-job error policy? I mean I don't quite get what unless otherwise specified for the printer means here - it is in description for every error policy, but I don't see a way how to influence a queue with retry-current-job policy...

[michaelrsweet]

@zdohnal The "retry-current-job" behavior is usually for reprinting as raster (you try sending PDF, that fails, then you send the job as a raster file) or for ensuring that jobs are only printed in the queue order. "retry-job" reschedules the job (allowing another job to print ahead of it) and is typical for fax jobs.

[zdohnal]

@michaelrsweet ok, I see - although I still miss how user can specify something different for the printer. That's how I understand the sentence unless otherwise specified for the printer - user or someone can somehow specify a different behavior for the policy.
I can imagine a driver dev can implement a different functionality in their backend and still return a backend exit code for retry-job or retry-current-job - is it what the sentence means? That it depends on drivers backend how it implements the behavior which generates backend exit code matching with the policy?

[michaelrsweet]

@zdohnal It is the exit code from the backend - a generic failure (exit code 1) triggers the configured error policy. If the backend returns one of the other status codes then it does that - see "man backend".

[zdohnal]

@michaelrsweet Ok, then shouldn't the sentence unless otherwise specified for the printer be removed from error policy man pages, since there is hardcoded behavior for each error policy?

Additionally, JobRetryInterval should not mention retry-current-job, since it is not used with the policy?

[michaelrsweet]

@zdohnal First, "retried immediately" doesn't mean "without delay", it means "without intervening jobs". I wish there was a clearer way to say this without getting overly wordy.

Second, the only "hardcoded" behavior in the standard backends is for conditions that are extraordinary - a print failure the printer says is due to the file (and you need to reprint as raster), a networking or security issue that is going to prevent all jobs from working, etc. The error policy is there for the issues the backend isn't able to clearly diagnose or when the proper response isn't obvious.

[zdohnal]

Fixed in #1195 , but I referenced bad issue...