How soon can JobDeliveryStausRequest be checked?

Options

Typically, as we submit a new fax and get a jobID, the endpoint that serves JobDeliveryStatus is ready to go immediately. We check the first status after 67 seconds to catch the initial errors like 2006, 6500, 5103, 9001, etc., and then we check the status progressively in respect to the fax size. It works fine, but there are some rare cases when the 67 second status check does not return any status.  We consider this an abnormality and initiate a resend from our side. Interestingly, all the resents failed with the same pattern: no job status (xsi-1823050305, xsi-1497425536, xsi-1823052613, xsi-1823052856). Despite this, OT does deliver the jobs successfully after they fail to report status at 67 seconds. So, what is your internal logic for when job status becomes available? Why is it available instantly in most cases, but in some rare instances, the status availability has a delay? We can certainly fix this on our side by allowing the job status absence to not be a terminal event. We can queue the failed status jobs, or we could extend those 67 seconds to a few minutes, but it would be helpful to know what happened on the OT side in terms of status availability.

 

Tagged:

Comments

  • mparvathi_2021
    mparvathi_2021 Moderator, E mod
    Options

    We are looking into the issue for the jobs provided and get back you as soon as we can

  • mparvathi, do you have any update?

  • mparvathi_2021
    mparvathi_2021 Moderator, E mod
    edited May 28, 2021 #4
    Options

    Hi Romy,

    Sorry for the delay in response..

    For the jobs provided, JobDeliveryStatus didn't return the status because the jobs are not delivered at that time. We have observed a delay in processing at that time from one of our backend processes due to heavy load. So that is the reason why you haven't received the status.

    From our side there is no explicit logic/formula to say after a particular time you can try for status check because the job processing entirely depends on many circumstances like traffic, size, recipients etc. So we suggest you to keep polling longer period with longer intervals.

    Thanks

  • Thank you very much, mparvathi, I was under impression that is case your back end is busy and status not yet available you throw some kind of default status, like in-progress. Anyhow, now I know how to deal with it and I will permit "null status" as a valid response.