Releases: daneren2005/php-resque
1.2.37
Improve some logging if we fail to remove working status
1.2.36
Fix requeued jobs sometimes marking as failed in job status until restarted
If we don't clear currentJob from checkForRequeuedJob, then in unregisterWorker we are marking the status as failed. The status would be fixed when we ended up starting the job, but if we were watching for the status it would briefly show the wrong status.
1.2.35
Fix receiving sigkill after pulling job from stack but before starting forking
Before if we received a sigkill after pulling from stack but before starting the forking process, we would end up handling the sigkill, then resuming the forking process. The child process would be started, and then hard killed once the parent process was done shutting itself down, resulting in a stranded job.
1.2.34
Added a standard log on the worker parent so we can track cases where the child worker died without any direct logging, and added verbose log when the parent completes a child process to help with debugging.
1.2.33
$this->child = Resque::fork()
breaks if we receive a kill signal after pcntl_fork
but before the child is set. We will now track if we are in the middle of a fork and wait for the forking process to finish, then kill the child properly so we don't strand a job in the "working" state.
1.2.32
Previously we would create the status with an expiration, and then update it to not have an expiration on the first update, and then give an expiration back when complete. I want to keep it always expiring after a day of nothing happening since that means it is probably broken somehow.
It has also been switched from set
then expire
to using setex
so that it is atomic and a stop signal after set but before expire won't break the expiration. It is also slightly faster being in a single redis call.
1.2.31
Trying to bump release to get packist to work
1.2.30
Upgrade psr/log to 1.1x branch to fix incompat with modern versions of phinx
1.2.29
Update psr/log dependency to be any modern version
1.2.28
Auto retry to killChild
I am seeing a specific case where a job starts at the exact same time as it receives a shutdown signal. The child goes on to start the job and never gets requeued when it gets hard killed a moment later. My best guess is it is from trying to kill the child before it is fully started. I do not have a reliable way of reproducing this issue outside of production