dmolnarqu
commented
2 years ago There are not nearly enough details in the report to be actionable now of in the future. There is only claim about "some" lock existing, and the symptoms of the stuck lock don't add up. Unless you wish to extend the report with more details I am going to close it. It would be useful to clarify these things:
- Was it queue lock or running lock?
- There's no proof the lock was related to the job in question.
- How is it possible that the any emails were sent, even though the lock existed? (it prevents the job from running)
- Reschedule is a part of normal operation for email jobs. What was special about the mentioned reschedules?
- The lock has been made stuck by the error in client PHP code. This seems impossible, because the queue lock is unlocked before the client code is even initialized, so I don't see how this could happen. Running lock, on the other hand, does get cleared automatically after a certain period of time. (unless the worker is actually running)
Edit: There's already proof that queue locks can get stuck for an unknown reason, but I don't think this report can help solve the issue.
mpizem
If I now we have mechanism what is doing removing resque locks. But customer
ftmo.ladesk.comhas already lock 2 times and lock was not removed automatically. We don;t know what caused first lock but second lock seems was caused by error during execution of mass action job. Error is reported here https://github.com/QualityUnit/la-issues/issues/13439.Whole situation caused number of emails send was just ~4 emails per hour and there was >1000 emails to be send. It seems the mostly emails instead of send was rescheduled.