PDFs may get stuck in the "processing" state
Currently the Flask process puts a row into the PDF table with status "processing", and then launches a subprocess, passing in the ID of this row. The subprocess then updates the row, and finally puts an "error" or "success" status before exiting.
If this fails for some reason (e.g. zesje has a bug, or we forcefully kill the process) then there are rows in the DB lying around with the "processing" status. This will be confusing to users, as they will see this status forever, and it looks like something is happening when really it is not.
A solution is to save the process ID of the subprocess into the database row also.
Then, on every GET /pdfs/<exam_id>
we first iterate over all the relevant rows in the PDF table (say, only those associated
with exam_id
for efficiency's sake) and check, for all the "processing" rows, that the recorded PID is still alive. If it is not,
then we remove the corresponding row from the table. This can in principle produce false negatives (rows not removed, even though
they are stuck in the "processing" state and their subprocess has died) due to PID reuse, but in practice this is unlikely to be a
problem.
We can use the psutil
module to check for existence of PIDs in a cross-platform way.