`fj run view --log/--log-failed` reports "no logs" for every run even when logs exist #92

New issue

Closed

opened 2026-06-10 15:01:25 +00:00 by stephen · 1 comment

stephen commented

2026-06-10 15:01:25 +00:00

Owner

What happened

Against rasterstate/flux on rasterhub.com, every form of log retrieval fails for every run, regardless of run outcome:

$ fj run view 171 --log
error: no logs for that run/job/attempt
$ fj run view 171 --log-failed
error: no logs for that run/job/attempt

This reproduces for successful runs and failed runs alike, including runs whose logs are fully visible in the web UI and whose step logs exist in the Forgejo DB (action_task_step.log_length is nonzero for the same tasks).

Why it matters

The error message reads as "the job died before producing logs", which sent a real CI triage down a long detour (chasing runner provisioning, autoscaler limits, and log shipping) when the actual failure was an ordinary step failure whose logs existed the whole time. Ground truth had to come from sqlite on the server:

docker exec forgejo sqlite3 -readonly /data/gitea/gitea.db \
  "SELECT task_id, \`index\`, name, status, log_length FROM action_task_step WHERE task_id IN (...);"

Expected

fj run view <n> --log prints the step logs when they exist; "no logs" is reserved for runs that genuinely produced none.

Environment

Forge: rasterhub.com (Forgejo 11.0.x)
Repo observed: rasterstate/flux (private), runs both from pull_request and workflow_dispatch
Possibly related: this Forgejo build omits the job attempt field in some API responses, so an attempt-keyed log lookup may be missing its key rather than the logs being absent.

## What happened Against `rasterstate/flux` on rasterhub.com, every form of log retrieval fails for every run, regardless of run outcome: ``` $ fj run view 171 --log error: no logs for that run/job/attempt $ fj run view 171 --log-failed error: no logs for that run/job/attempt ``` This reproduces for successful runs and failed runs alike, including runs whose logs are fully visible in the web UI and whose step logs exist in the Forgejo DB (`action_task_step.log_length` is nonzero for the same tasks). ## Why it matters The error message reads as "the job died before producing logs", which sent a real CI triage down a long detour (chasing runner provisioning, autoscaler limits, and log shipping) when the actual failure was an ordinary step failure whose logs existed the whole time. Ground truth had to come from sqlite on the server: ``` docker exec forgejo sqlite3 -readonly /data/gitea/gitea.db \ "SELECT task_id, \`index\`, name, status, log_length FROM action_task_step WHERE task_id IN (...);" ``` ## Expected `fj run view <n> --log` prints the step logs when they exist; "no logs" is reserved for runs that genuinely produced none. ## Environment - Forge: rasterhub.com (Forgejo 11.0.x) - Repo observed: rasterstate/flux (private), runs both from `pull_request` and `workflow_dispatch` - Possibly related: this Forgejo build omits the job `attempt` field in some API responses, so an attempt-keyed log lookup may be missing its key rather than the logs being absent.

stephen added the

backlog

label

2026-06-10 21:00:11 +00:00

stephen commented

2026-06-10 23:49:52 +00:00

Author

Owner

Duplicate of rasterstate/fj#91, which carries the full root-cause analysis.

Same defect, second repro: fj run view --log/--log-failed returns "no logs" for every run on a private repo regardless of outcome. rasterstate/fj#91 traces it to fj POSTing the Forgejo web log route (/{owner}/{repo}/actions/runs/{n}/jobs/{j}/attempt/{a}) with API-token auth, which a private repo answers with a 404 because that route wants session-cookie + CSRF, not a token. log_route_error in src/api/workflow_view.rs then maps every 404 to "no logs for that run/job/attempt", masking the auth failure as a missing run.

The two useful details from this report are folded into rasterstate/fj#91:

logs are confirmed present in action_task_step.log_length server-side while fj reports none, and
this Forgejo build (11.0.x) omits the job attempt field in some API responses, which is consistent with the attempt-keyed lookup failing.

Closing as a duplicate. Tracking the fix and the private-repo test in rasterstate/fj#91; the deeper "actually retrieve private-repo logs" work is split out separately and linked from there.

Duplicate of rasterstate/fj#91, which carries the full root-cause analysis. Same defect, second repro: `fj run view --log/--log-failed` returns "no logs" for every run on a private repo regardless of outcome. rasterstate/fj#91 traces it to `fj` POSTing the Forgejo **web** log route (`/{owner}/{repo}/actions/runs/{n}/jobs/{j}/attempt/{a}`) with API-token auth, which a private repo answers with a 404 because that route wants session-cookie + CSRF, not a token. `log_route_error` in `src/api/workflow_view.rs` then maps every 404 to "no logs for that run/job/attempt", masking the auth failure as a missing run. The two useful details from this report are folded into rasterstate/fj#91: - logs are confirmed present in `action_task_step.log_length` server-side while `fj` reports none, and - this Forgejo build (11.0.x) omits the job `attempt` field in some API responses, which is consistent with the attempt-keyed lookup failing. Closing as a duplicate. Tracking the fix and the private-repo test in rasterstate/fj#91; the deeper "actually retrieve private-repo logs" work is split out separately and linked from there.

stephen closed this issue

2026-06-10 23:49:52 +00:00

stephen referenced this issue

2026-06-10 23:49:52 +00:00

Retrieve Actions logs on private repos (token-accepting path or cookie/CSRF auth) #103

stephen referenced this issue

2026-06-10 23:50:28 +00:00

fj run view: distinguish private-repo log auth failure from a missing run, instead of masking it as "no logs" #91

stephen referenced this issue

2026-06-11 02:30:23 +00:00

Retrieve Actions logs on private repos (token-accepting path or cookie/CSRF auth) #103