# Submission details and cancellation

Tables keep values on one line, with wider ID, status and other metadata columns.
Long errors can be viewed in the bordered report panel. Select a row, then open
"Submission details / report / cancellation" and click "View / refresh report".
The submission ID can also be entered manually. Only the signed-in owner's
submissions for that task are accessible; deleted records are excluded.

The report is a snapshot assembled from existing queue, history and progress
records, including submission status, stored per-scene errors and the current
stage. Reports never include per-scene scores or aggregate score/metric payloads;
aggregate scores remain available in the leaderboard and history tables.
Archived progress is used when available. It is not raw
container output or a complete historical event trace. Errors already truncated
by the worker cannot be reconstructed. Refresh to see subsequent progress.

The report can be copied or downloaded as `.log`. No additional permanent
worker logs are created. A temporary frontend report is overwritten for each
submission; files older than one day are cleaned on report generation, and the
Gradio download cache is cleaned hourly with a one-day lifetime.

"Cancel submission" sends a request to the Worker for a pending or running job.
The Worker checks ownership and task. Pending jobs are removed from the queue;
running jobs receive a persisted cancellation flag. The evaluation subprocess
is terminated (with a kill fallback after 10 seconds), then its attempt directory
is cleaned before the job becomes `cancelled`. Downloads and validation stop at
the next safe checkpoint; ZIP extraction checks between chunks. If subprocess
evaluation is disabled, an active in-process evaluation must finish before the
Worker can honour cancellation. Request processing normally runs every 30 seconds;
the scoring subprocess checks accepted cancellation every 2 seconds.
Already completed submissions cannot be cancelled. Cancellation acceptance and
finalization use the same processing-record lock: whichever commits first wins.
Refresh the report to inspect cancellation request status and reason.
Terminal reports also expose `cleanup_pending`: true means a tracked temporary
attempt still awaits cleanup. The Worker retries cleanup every 60 seconds;
refresh the report to update this flag. Shared download caches and ordinary
history/progress records are retained. A cancelled status alone does not certify
that filesystem cleanup succeeded.
Cancelled submissions remain in history and can be deleted through the existing
history deletion feature. Deploy both Frontend and Worker for cancellation.

All tasks share the Worker executor. Its default concurrency is 1, overridable
with `WORKER_CONCURRENCY` in the Worker environment. Fresh submissions are claimed
by pending-file modification time (FIFO); unfinished recovered work is preferred.
Queue positions include submissions outside the currently displayed task/account.
Scheduling and concurrency are not changed by these UI updates.