My question is a general one about the nature of a queued job in redis. My Laravel job involves a call to a remote API which involves a back and forth to generate a timetamp hash related to authorization to make the next call. This hash is only good for about 5-10 seconds. After that time has passed, if the hash is used to make the final call, it will be rejected. In other words, if the process is slow for some reason, it will fail.

After a job is queued, when it finally runs will it run "real-time" in light of the hashing process described above? Or, does it use the time of when the job was queued? I've had a lot of failures today during times of rapid job use. The jobs technically should have been fine, so it's been a bit of a stumper and my current theory is the hash is bad.

I changed the timeout of the job to 5 seconds and it appeared the queue stayed fuller longer, and there was only 1 failed out of 30 run, rather than a failure rate of 100% when there is more than 8 in the queue (and there are 8 processes running with supervisor).

I am also unsure of whether the timeout method would re-queue the job after 5 seconds of being in the queue, or if it re-queues the job after 5 seconds of being run after it's no longer in the queue.