Bug
Premature job execution due to eager paging
Issue description
It can happend, that a service scheduled a job, which implicitly pages the job runner, but when he executes the run-job command, the service call fails because the job id is not found in the database.
Developer comments
The jobs files are written immediately after the jobs are inserted into the MySQL database. But the transaction has not yet been commited. This causes the separate MySQL connection to run into a non-existing, or better not-yet-existing, job id.
This issue should be resolved by applying this fix: It must be ensured that when the job files are written, the corresponding job rows are already committed. So the complete fault in this case is at the service request that wrote inconsistent data. The job runner behaved ok. It logged the problem and forgot about it. The best way to ensure correct behavior would be to simply write it outside a DB transaction or simply right after the DB commit took place.
The jobs were written too early. But also: this could only take effect when there was a significant time after the commit still spent in the request. In the case at hand it is the copying of several large files which were fetched from a remote server and put in the database. They are only copied to the destination in the database after the MySQL transaction is comitted. This caused the job runner to pick up the file and not find the job.
Unfortunately this could not be confirmed by tests either.
|
Work sessions2
Start |
2023-06-06T07:00:00
|
End |
2023-06-06T11:23:15
|
Participant |
Robert Cerny
|
Start |
2023-06-07T08:10:37
|
End |
2023-06-07T12:01:08
|
Participant |
Robert Cerny
|
|
We are sorry
This page cannot be displayed in your browser. Use Firefox, Opera, Safari, or Chrome instead.