fix(forgejo): watchdog covers manual auto-apply dispatch #261

Merged

pdurlej merged 1 commit from codex/hardening/deploy-runner-watchdog-dispatch into main

2026-05-13 18:35:00 +02:00

codex commented

2026-05-13 09:12:23 +02:00

Collaborator

Canary status: missing — fire canary 3+3 manually before merge

Canary Context Pack

Product story

The deploy runner watchdog is supposed to recover waiting trusted-main auto-apply jobs without operator/Codex manually restarting forgejo-deploy-runner.service. During dashboard/F1.5 manual smokes, workflow_dispatch jobs stayed waiting until the service was restarted. The watchdog said no stuck jobs because it only watched push events.

What changed

Extends scripts/forgejo/deploy-runner-watchdog from ar.event = 'push' to ar.event in ('push', 'workflow_dispatch').
Adds tests proving the watchdog SQL covers both event types and restarts only the dedicated deploy runner service.

Why it changed

Manual cutover smokes are launched with workflow_dispatch. Recent evidence showed stuck manual auto-apply jobs are invisible to the current watchdog query.

Files touched

scripts/forgejo/deploy-runner-watchdog
tests/test_deploy_runner_watchdog.py

Relevant context

Issue #260
Issue #142 F1.5 cutover lane
Dashboard run #612/#621 and matrix run #635 required runner service restart after waiting

Runtime evidence

Read-only Forgejo DB sample showed manual auto-apply runs with event=workflow_dispatch, ref=refs/heads/main, and later task assignment after runner restart.

Known constraints

This PR does not change timer frequency or systemd units.
It does not restart any production application containers.
The watchdog still only restarts forgejo-deploy-runner.service and keeps the existing waiting/ref/task_id guardrails.

Explicit out-of-scope

No app deploy.
No production service restart.
No Forgejo runner version upgrade.
No watchdog installation change on RS2000 until after merge.

Requested decision

Merge so Codex can sync the updated watchdog to /opt/pdurlej-platform/current and install it before further manual no-op smokes.

Merge blockers

Tests fail.
Review finds workflow_dispatch auto-apply jobs should not be watchdog-restarted.

Spec sources read

scripts/forgejo/deploy-runner-watchdog — changed script.
runbooks/forgejo-actions-runner.md — watchdog context.
RS2000 systemd/journal read-only evidence — observed watchdog behavior.
Forgejo DB read-only sample — event type evidence.

Verification

/tmp/platformctl-test-venv/bin/pytest tests/test_deploy_runner_watchdog.py tests/test_platform_host_agent_wrapper.py -q

Result: 9 passed.

Closes #260
Refs #142

Canary status: missing — fire canary 3+3 manually before merge ## Canary Context Pack ### Product story The deploy runner watchdog is supposed to recover waiting trusted-main auto-apply jobs without operator/Codex manually restarting `forgejo-deploy-runner.service`. During dashboard/F1.5 manual smokes, workflow_dispatch jobs stayed waiting until the service was restarted. The watchdog said no stuck jobs because it only watched push events. ### What changed - Extends `scripts/forgejo/deploy-runner-watchdog` from `ar.event = 'push'` to `ar.event in ('push', 'workflow_dispatch')`. - Adds tests proving the watchdog SQL covers both event types and restarts only the dedicated deploy runner service. ### Why it changed Manual cutover smokes are launched with `workflow_dispatch`. Recent evidence showed stuck manual auto-apply jobs are invisible to the current watchdog query. ### Files touched - `scripts/forgejo/deploy-runner-watchdog` - `tests/test_deploy_runner_watchdog.py` ### Relevant context - Issue #260 - Issue #142 F1.5 cutover lane - Dashboard run #612/#621 and matrix run #635 required runner service restart after waiting ### Runtime evidence Read-only Forgejo DB sample showed manual auto-apply runs with `event=workflow_dispatch`, `ref=refs/heads/main`, and later task assignment after runner restart. ### Known constraints - This PR does not change timer frequency or systemd units. - It does not restart any production application containers. - The watchdog still only restarts `forgejo-deploy-runner.service` and keeps the existing waiting/ref/task_id guardrails. ### Explicit out-of-scope - No app deploy. - No production service restart. - No Forgejo runner version upgrade. - No watchdog installation change on RS2000 until after merge. ### Requested decision Merge so Codex can sync the updated watchdog to `/opt/pdurlej-platform/current` and install it before further manual no-op smokes. ### Merge blockers - Tests fail. - Review finds workflow_dispatch auto-apply jobs should not be watchdog-restarted. ## Spec sources read - `scripts/forgejo/deploy-runner-watchdog` — changed script. - `runbooks/forgejo-actions-runner.md` — watchdog context. - RS2000 systemd/journal read-only evidence — observed watchdog behavior. - Forgejo DB read-only sample — event type evidence. ## Verification ```bash /tmp/platformctl-test-venv/bin/pytest tests/test_deploy_runner_watchdog.py tests/test_platform_host_agent_wrapper.py -q ``` Result: 9 passed. Closes #260 Refs #142

codex added 1 commit

2026-05-13 09:12:24 +02:00

fix(forgejo): watchdog covers manual auto-apply dispatch

canary-required / collect-diff (pull_request) Successful in 4s

Details

python-ci / Python 3.11 (pull_request) Successful in 33s

Details

python-ci / Python 3.12 (pull_request) Successful in 34s

Details

python-ci / Python 3.13 (pull_request) Successful in 34s

Details

canary-required / canary (pull_request) Successful in 12s