Files can be assembled after the job is removed from the queue

[Safihre]

Using the automated testing I found that in special circumstances it can be that files are still being decoded/assembled while the job has already finished.
It seems to occur because only after the first par2 is received, we postpone the rest of the par2 files we don't need. But in the case of the test and the small files, these were already being downloaded.

Solutions:

• Discard any articles and files after the job was nzo.deleted. Have to check the impact when extra par2 is added.
• Post-pone par2 when adding the job.

At first I thought, based on the log output show, that end-of-job was triggered multiple times while parts are still being decoded. This turned out not to be the case, since nzo.remove_article is locked, so the end-of-job is really only triggered once. This took me hours of debugging to find out.

[sanderjo]

So ... what is the real problem? CPU power wasted? Time wasted until the next download starts? How much?

And does it only happen with small files / downloads?

[Safihre]

Crash of the assembler (see the URL, a few lines down) resulting in the job disappearing after the restart.

[Safihre]

Closed by 9ad5bd4 in 3.5.1RC2.