investigate: called-workflow job logs return HTTP 500 via API (Forgejo 17 / gitea-1.22) #5

New issue

Open

opened 2026-11-12 21:25:12 +00:00 by hermes_forgeron · 0 comments

hermes_forgeron commented

2026-11-12 21:25:12 +00:00

Collaborator

Part of #1 (finding 4). Probably a Forgejo bug rather than ai-factory code — this issue is a triage.

Observed

On factory.serious-devs.io (Forgejo 17.0.0+gitea-1.22.0), for a run that delegates through a cross-repo reusable workflow (uses: serious-devs/ai-factory/.forgejo/workflows/agent.yml@main), the run reports two jobs:

agent — the called reusable workflow's job → GET /api/v1/repos/{o}/{r}/actions/jobs/{id}/logs returns HTTP 500 with body {"message":"","url":"…/api/swagger"} (empty message);
agent-1 — the thin wrapper's job → HTTP 200 with the full log (which includes the nested job's output).

Seen on runs 892 (jobs 3497 → 500 / 3498 → 200), 895, 898, 901.

Triage steps

In the web UI, open one of those runs and the agent job: does the log display? (UI fails too → server-side log storage bug for called jobs; UI works → API-only bug.)
Search Forgejo (codeberg.org/forgejo/forgejo) and Gitea (github.com/go-gitea/gitea, v1.22+) for existing reports: "workflow_call job logs 500", "reusable workflow logs", "actions job logs empty message".
If a second Forgejo/gitea-1.22+ instance is available, reproduce there with a minimal reusable-workflow run to confirm it is generic.
Decide: instance-fixable, upstream bug, or works-as-intended.

Acceptance criteria

Reproduction documented (UI vs API behavior, exact version)
Root cause identified: instance-fixable / upstream bug (with upstream issue link) / works-as-intended
If instance-fixable: fix applied and the endpoint returns 200 for agent jobs
If upstream: report filed upstream with the reproduction, and the wiki page Limitations entry ("The agent job's logs are not retrievable via API") updated to link it
If works-as-intended: wiki entry updated with the explanation and the working alternative (read the wrapper job's logs)

Part of #1 (finding 4). Probably a Forgejo bug rather than ai-factory code — this issue is a triage. ## Observed On `factory.serious-devs.io` (Forgejo `17.0.0+gitea-1.22.0`), for a run that delegates through a cross-repo reusable workflow (`uses: serious-devs/ai-factory/.forgejo/workflows/agent.yml@main`), the run reports two jobs: - `agent` — the called reusable workflow's job → `GET /api/v1/repos/{o}/{r}/actions/jobs/{id}/logs` returns **HTTP 500** with body `{"message":"","url":"…/api/swagger"}` (empty message); - `agent-1` — the thin wrapper's job → HTTP 200 with the full log (which includes the nested job's output). Seen on runs 892 (jobs 3497 → 500 / 3498 → 200), 895, 898, 901. ## Triage steps 1. In the web UI, open one of those runs and the `agent` job: does the log display? (UI fails too → server-side log storage bug for called jobs; UI works → API-only bug.) 2. Search Forgejo (codeberg.org/forgejo/forgejo) and Gitea (github.com/go-gitea/gitea, v1.22+) for existing reports: "workflow_call job logs 500", "reusable workflow logs", "actions job logs empty message". 3. If a second Forgejo/gitea-1.22+ instance is available, reproduce there with a minimal reusable-workflow run to confirm it is generic. 4. Decide: instance-fixable, upstream bug, or works-as-intended. ## Acceptance criteria - [ ] Reproduction documented (UI vs API behavior, exact version) - [ ] Root cause identified: instance-fixable / upstream bug (with upstream issue link) / works-as-intended - [ ] If instance-fixable: fix applied and the endpoint returns 200 for `agent` jobs - [ ] If upstream: report filed upstream with the reproduction, and the wiki page `Limitations` entry ("The `agent` job's logs are not retrievable via API") updated to link it - [ ] If works-as-intended: wiki entry updated with the explanation and the working alternative (read the wrapper job's logs)

hermes_forgeron referenced this issue

2026-11-12 21:25:13 +00:00

Dogfood findings: reliability improvements for the agent workflow #1

hermes_forgeron referenced this issue

2026-11-14 15:01:01 +00:00

agent: honor the caller's event under workflow_call (#2) #6