Fix and resubmit
A request is met without a file change, or by a changed task. You send a changed task again under a new collection name and withdraw the old task.
A request is met in one of two ways. A build that stopped at something outside the task's files is met with "Check again", and the same task goes on. Every other request needs a changed task. You send the changed task again under a new collection name, and you withdraw the old task.
A request met without a file change
One kind of request needs no change to the task's files: a miss of IS-6, when the build stopped at something outside the task's files. Examples are a download that is back, or a base image that is published again.
| Step | What you do | What you see |
|---|---|---|
| 1 | Put right what the build stopped at | "Needs from you", with the line of the build |
| 2 | Choose "Check again" on the task | "Checking" |
| 3 | Wait for the intake checklist | The checklist of the new run |
"Check again" does not read your archive again. The task's files are the copy stored when the task was pinned. A rule that the files missed would be missed again. So "Check again" is offered for IS-6 alone.
If the build still stops, the task returns to "Needs from you", with the line of the new run.
A changed task is sent again
Every other request needs the task's files to change. The same is true after a flawed verdict. The task's files are pinned, so a change is never made in place.
The dashboard says this on the task: "This task has to change before it can go on. A changed task is sent as a new submission under a new collection name. This one can be withdrawn."
To send a changed task:
- Change the task in your own copy.
- Put the task folder in a new archive.
- Submit the archive under a new collection name. A collection name is used once.
- Confirm the task in the preview.
- Withdraw the old task, if it is not yet published.
The changed task is audited from the start. Submit tasks describes the steps of a submission.
What happens to the old task
Under a new collection name, the changed task is another task. Horizon Audit does not link it to the old one.
- An old task that shows "Needs from you" keeps waiting until you withdraw it. Sending the changed task does not close its request. Withdrawing it does.
- An old task that is published keeps its result. A "Flawed" result stays with the files it was given for.
- A verdict holds for the exact files that were audited. Each task is pinned to a digest of its files, so a "Clean" result on the old task says nothing about the changed files.
Withdraw a task
You can withdraw a task in any state before it is published. Choose "Withdraw" on the task. The task then shows "Withdrawn". It will not be audited, and this cannot be undone. A run that was in progress is stopped.
Two other actions also give "Withdrawn":
- A task that you deselect in the preview becomes "Withdrawn" when you confirm.
- If you cancel a submission before you confirm it, all of its tasks become "Withdrawn".
A published task cannot be withdrawn.
Horizon Audit does not fix your task
The audit says what is wrong and proves it. It does not suggest a fix. A request names what is needed and where, and never says how to write it. A finding gives the flaw, its location and the proof, and nothing more.
Horizon Audit never edits a task to make it run. The task is run as it is written. You change the task and send it again.
Read a verdict says what a result contains. The intake standard lists the line for each request.