substrate observation: Forgejo Actions workflow_runs API can report success without actual job execution (trusted-proxy trap) #47
Labels
No labels
bump
major
bump
minor
bump
patch
kind/bug
kind/chore
kind/docs
kind/feature
priority/critical
priority/high
priority/low
priority/medium
size/L
size/M
size/S
size/XL
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
frankenbit/release-toolkit#47
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Why (surfaced from #41 disposition (A) probe attempt + Surveyor cb42 framing)
The v0.3.3 cycle's autonomous
debug-event-payload.ymlprobe (PR #45 close, 2026-06-24 23:11) is recorded by Forgejo'sworkflow_runsAPI as run 6176,status=success,workflow_id=debug-event-payload.yml. The Forgejo Actions UI also shows green.But no task log was produced. Probing the runner's task scheduler:
prep.preptask fired (release-prep on prep PR close — release.yml workflow) — failedcheck.checktask fired (manifest-check on prep PR close) — succeededdraft.drafttask fired (release-draft on prep PR close — release-draft.yml) — failed per #41dump-event.dump-eventtask — debug-event-payload.yml's job never scheduledSo the workflow_runs API recorded
successfor a workflow whose job NEVER RAN. Status-without-execution.Per Surveyor cb42 framing
Same family as
Three instances of the trusted-proxy-hides-no-execution family across three different surfaces. Worth promoting to a named pattern if a fourth lands.
Proposed disposition
(A) Forward-watch. This is an upstream Forgejo Actions behavior we can't fix from the consumer side. Worth banking as a discoverability discipline: "trust the job log, not the run-status" applies to every cross-cycle verification.
(B) Consumer-side hardening (future). When verifying a workflow ran correctly, canonical-probe should descend to the task-log level — not stop at
workflow_runs[id].status. Could add a helper script that mapsrun_id → task_id → log_file_exists+nonemptyfor automated verification.(C) Upstream Forgejo bug report if the behavior is unintended. Worth a Forgejo issue link/file if not already known.
Disposition lean
(A) for now — banking + cross-referencing on related trackers. (B) is a defensive-coding follow-up if the pattern bites again.
Worked instance trace
actions_log/frankenbit/release-toolkit/task logs for that time range: 12986/12988/12990/12993 — allprep.prep/check.check/draft.draft, NOdump-event.dump-event— QM, 2026-06-25, surfaced from v0.3.4 sprint slice 1 verification.
Closing with disposition: documented as substrate-state limitation, banked in AGENTS.md §8 Axis C (trusted-proxy at report layer).
Per the v0.6.2 substrate sweep (#97 merged 2026-06-26):
workflow_runsAPI for verification, so the trusted-proxy trap doesn't bite our code path.workflow_runsfor verification (e.g., a "did the publish workflow run?" check), apply the discipline: read the job log + verify the artifact, don't trust the run-status. Surveyor cb42 framing carries forward.Closing as documented; reopening would be appropriate if a future toolkit feature actually needs to read
workflow_runs+ we need to write defensive code at that consumption point.