Problem When a job (page move, rename or delete, extension install or upgrade, etc.) stops before its end because its thread is interrupted, typically because XWiki is stopped while the job runs, its status page shows the red error box "Failed." followed by the job log. With XCOMMONS-3824 such a job ends in state FINISHED with an error caused by an InterruptedException (or a ClosedByInterruptException) and, when the job is cancelable, with the canceled flag set. The user cannot tell a job that failed from a job that was stopped half way, and "Failed." does not say that part of the work was done and the rest was not. The job status template checks the error before the canceled flag, so a canceled job which ended with an error is also displayed as failed. In addition, the displayJobStatus macro of job_macros.vm passes $status instead of its own $jobStatus parameter when it displays the message of a finished job, so the pages using this macro (attachment move status, page restore, filter stream job, etc.) display "Done." for any finished job, failed ones included, when they are loaded after the end of the job. Proposal
- A finished job which ended with an error and either is canceled or has an interruption (InterruptedException, ClosedByInterruptException) in the cause chain of its error is displayed with a warning: "Interrupted before completion, for example because the server was stopped. Some of the work might not have been done." (new translation key job.status.interrupted, which can be overridden per job type and per translation prefix like the other job status messages), followed by the job log as for a failed job.
- Real failures keep the error box, and canceled jobs without error keep "Canceled.".
- displayJobStatus uses the job status it receives.
- The status refreshed by the browser while a job runs (job_status_json.vm, used by job.js) is computed by the same macro, so both displays stay consistent.
|
