fix(review): keep fallback marker until workflow completion

[JSONbored]

Motivation

• The fallback dispatch marker was being cleared for any matching workflow_run activity, including non-terminal requested/in_progress events, which can cause redispatch -> cancel-in-progress loops and availability loss for visual fallback captures.
• The intent is to only clear the persisted in-flight marker once the fallback workflow has actually settled (terminal/completed), while preserving the existing behavior that clears the marker for final states (success/failure/cancel/timed_out).

Description

• Add a guard in maybeCaptureOnActionsFallbackWorkflowRun to ignore non-terminal webhook deliveries by returning early unless payload.action === "completed" (in src/queue/processors.ts).
• Keep the existing behavior that clears the marker on settled runs and still stores successful-run artifacts and triggers a re-review when appropriate.
• Add a regression unit test that seeds an in-flight marker, sends a non-terminal workflow_run webhook (action: "requested"), asserts no artifact-list fetch happens, and verifies the marker remains present (in test/unit/actions-fallback-webhook.test.ts).

Testing

• Ran the focused unit file with npx vitest run test/unit/actions-fallback-webhook.test.ts --pool=forks --reporter=verbose and the test suite for that file passed (all tests in that file passed).
• Ran npm run typecheck and git diff --check, both of which succeeded with no type errors or repository hygiene issues found.
• Attempted the full coverage run via npm run test:coverage; the broader suite did not complete in this environment (long-running queue suite) and was terminated, and npm run test:coverage -- --runInBand failed due to Vitest not recognizing --runInBand.

---

Codex Task

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.71%. Comparing base (b8a1ba4) to head (38250e2).
⚠️ Report is 34 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4186   +/-   ##
=======================================
  Coverage   93.71%   93.71%           
=======================================
  Files         385      385           
  Lines       36209    36210    +1     
  Branches    13266    13267    +1     
=======================================
+ Hits        33934    33935    +1     
  Misses       1618     1618           
  Partials      657      657           

Files with missing lines	Coverage Δ
src/queue/processors.ts	95.18% <100.00%> (+<0.01%)	⬆️

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[loopover-orb]

Warning

🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-08 10:33:12 UTC}

2 files · 1 AI reviewer · 2 blockers · readiness 93/100 · CI green · clean

⏸️ Suggested Action - Manual Review

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

Review summary
This adds a one-line early-return guard in maybeCaptureOnActionsFallbackWorkflowRun (src/queue/processors.ts) so the function only proceeds past the run-name/event check when payload.action === "completed", preventing the in-flight dispatch marker from being cleared on non-terminal workflow_run deliveries (requested/in_progress). GitHub's workflow_run event only ever fires action="completed" for the terminal delivery regardless of conclusion (success/failure/cancelled/timed_out all arrive as action="completed"), so this correctly narrows the marker-clearing path to actual settlement without disturbing the existing failed/cancelled/timed_out handling that runs after this guard. The added test drives the real processJob("github-webhook", eventName: "workflow_run") path with an action:"requested" payload and asserts both no artifact fetch and marker persistence, which exercises the genuine code path rather than a fabricated one.

Nits — 4 non-blocking

• The PR description doesn't cite a tracking issue number for the redispatch/cancel-in-progress loop being fixed — worth linking explicitly per repo convention even though this is clearly a continuation of the feat(review): GitHub-Actions build-and-serve fallback for repos with no CI preview deploy #4112 fallback-marker work.
• Worth confirming in the PR (or a follow-up) that a run stuck at requested/in_progress that never reaches completed (e.g., the workflow_run is deleted or the Actions run silently vanishes) still gets released via the marker's existing max-age/TTL rather than blocking redispatch indefinitely — not a regression from this diff, but this change makes that path slightly more load-bearing.
• Consider a brief inline comment at src/queue/processors.ts on the new guard noting that workflow_run's `action` is "completed" for all terminal conclusions (success/failure/cancelled/timed_out) — that's the non-obvious fact the whole fix hinges on, and a future reader may otherwise assume `action` tracks conclusion.
• If not already covered elsewhere, add a companion test for action: "in_progress" (not just "requested") since both are non-terminal and the guard treats them identically — cheap to add given the existing test's structure.

Concerns raised — review before merging

• No linked issue detected — If this PR is intended to solve an issue, link it explicitly in the PR body.
• Maintainer requires a linked issue — Link the relevant issue (for example Closes #123) before opening the PR.

Signal	Result	Evidence
Code review	❌ 2 blockers	1 reviewer
Linked issue	⚠️ Missing	No linked issue or no-issue rationale found.
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (no linked issue context).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 52 registered-repo PR(s), 43 merged, 486 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 52 PR(s), 486 issue(s).
Gate result	❌ Blocking	Repo-configured hard blocker found.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, TypeScript, JavaScript, Ruby, Go, Kotlin, MDX, Shell
• Official Gittensor activity: 52 PR(s), 486 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Explain no-issue PR.
• Link the issue being solved, or explicitly explain why this is a no-issue PR.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review