API returns 500 instead of 404 for action job logs when dbfs blob is missing

[shukiv]

Gitea version: 1.26.2
Storage backend: default dbfs (no [storage] or [storage.actions_log] section in app.ini)
Runner: act_runner host mode

Repro

Non-existent job id → clean 404:

curl -H "Authorization: token $TOK" \
  https://<host>/api/v1/repos/<owner>/<repo>/actions/jobs/99999999/logs
# HTTP 404
# {"message":"not found","errors":["run job with id 99999999: resource does not exist"]}

Existing job whose log blob is gone → 500:

curl -H "Authorization: token $TOK" \
  https://<host>/api/v1/repos/<owner>/<repo>/actions/jobs/7985/logs
# HTTP 500
# {"message":"OpenLogs: dbfs.Open \"actions_log/<owner>/<repo>/5a/1882.log.zst\": file does not exist"}

Same shape for /actions/runs/<id>/logs.zip.

Facts

• The action_run and action_task rows still exist; the run page shows failure with step list and durations.
• The dbfs blob the row points to is gone (OpenLogs: ... file does not exist).
• Gitea already has a working 404 path: it fires when the job id is unknown.

Ask

When the row exists but the dbfs blob is missing, return a clean 404 (or 410), same shape as the existing "unknown job id" 404. Don't 500.

I am not claiming retention/GC caused this — there is no custom [cron.cleanup_actions] config on this instance. The cause of the missing blob (failed persist by the runner, restart during upload, store-level orphan, …) is unknown and out of scope for this report. Surfacing it as 500 instead of 404 is the user-facing issue: it confuses operators trying to diagnose CI failures, and the run UI itself shows a generic "Failed to load asset file" toast on the affected jobs.

Happy to share journalctl output and a sanitised app.ini if useful.