SUBMISSION_REPORTS.md

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.