async fn reap_one(
conn: &mut PgConnection,
file_store: &dyn FileStore,
upload: &ReapableUpload,
) -> Result<bool>Expand description
Retires the binding, removes the object, and only then soft-deletes the file_uploads row.
Ok(false) means a submission came to reference the upload after get_reapable listed it, so
it is no longer reapable.
The order matters in both directions. Retiring the binding first means a submit naming this
upload answers upload_expired rather than succeeding and handing the exercise service a URL
that 404s. Deleting the file_uploads row last means get_reapable still sees the row after a
failed object delete and retries it on a later run, instead of orphaning the object forever.