Skip to content

fix(github-repo-monitor): silence 409 in fire_callback; document PATCH re-enable#275

Open
tofarr wants to merge 2 commits into
mainfrom
fix/github-repo-monitor-callback-409
Open

fix(github-repo-monitor): silence 409 in fire_callback; document PATCH re-enable#275
tofarr wants to merge 2 commits into
mainfrom
fix/github-repo-monitor-callback-409

Conversation

@tofarr
Copy link
Copy Markdown
Contributor

@tofarr tofarr commented May 29, 2026

Problem 1 — Noisy 409 in every run log

Every run of a github-repo-monitor automation logs:

Callback error (non-fatal): HTTP Error 409: Conflict

Root cause: The automation service marks a run COMPLETED on process exit.
The explicit fire_callback("COMPLETED") call at the end of the script then
tries to write the same status a second time and receives HTTP 409 Conflict.
Because this was caught by the bare except Exception handler it was printed
on every run, giving the impression something had gone wrong.

Fix (scripts/main.py): Catch urllib.error.HTTPError before the bare
Exception and return silently on 409.

Problem 2 — Vague 'local mode only' guidance

The previous intro callout said 'Local mode only' without giving agents a
concrete way to decide whether the current environment can receive GitHub
webhook events. In production Kubernetes pods AGENT_SERVER_URL and HOST
are absent, but RUNTIME_URL is set to a reachable external URL.

Fix (SKILL.md):

  • Replace the callout with an explicit RUNTIME_URL-based rule:
    set and not localhost/127.0.0.1 → prefer event trigger;
    unset, empty, or local → use cron polling.
  • Add Step 0 to the Setup Workflow so the agent runs
    echo "RUNTIME_URL=${RUNTIME_URL}" and surfaces the event-trigger
    recommendation to the user before proceeding with polling setup.

Additional docs (SKILL.md Troubleshooting table)

Two new rows:

Symptom Root cause Fix
Callback error (non-fatal): HTTP Error 409: Conflict in run logs
Race between process-exit auto-complete and explicit callback
Fixed in scripts/main.py (this PR)
Automation stops firing after a PATCH update
PATCH resets enabled to false
Follow every PATCH with {"enabled": true}

Testing

Discovered and verified in a live dev:automation stack running
github-repo-monitor against tofarr/polling-experiment.
Production K8s pod env-var inventory confirmed RUNTIME_URL as the
correct discriminator (not HOST or AGENT_SERVER_URL).

This PR was created by an AI agent (OpenHands) on behalf of the user.

…H re-enable

The automation service marks a run COMPLETED on process exit. The
explicit fire_callback("COMPLETED") call at script end then races
against that and receives HTTP 409 Conflict, producing a noisy
"Callback error (non-fatal)" line in every run log.

Fix: catch HTTPError 409 specifically and return without printing —
it means the run is already done, which is the desired state.

Also add two troubleshooting rows to SKILL.md:
- The 409 symptom, its root cause, and the fix.
- The PATCH-resets-enabled behaviour: after PATCHing an automation
  the service sets enabled=false; a follow-up PATCH {"enabled":true}
  is required to reactivate it.

Co-authored-by: openhands <openhands@all-hands.dev>
…E_URL check

The previous 'Local mode only' callout and the AGENTS.md guidance both
used 'local/sandboxed environment' as the criterion for choosing cron
polling over event triggers. This is imprecise — in production K8s pods
AGENT_SERVER_URL and HOST are absent, but RUNTIME_URL is set to a
reachable external URL.

Replace with a concrete, executable check:
  echo "RUNTIME_URL=${RUNTIME_URL}"

- set and not localhost/127.0.0.1 → environment can receive GitHub
  webhooks → prefer event-triggered automation
- unset, empty, or localhost → use cron polling (this skill)

Changes:
- Update the intro callout to reference RUNTIME_URL explicitly.
- Add Step 0 to the Setup Workflow so the agent checks RUNTIME_URL
  before proceeding and surfaces the event-trigger recommendation to
  the user when appropriate.

Co-authored-by: openhands <openhands@all-hands.dev>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants