Conversation
Automated sync from stranske/Workflows Template hash: 06f9a2f6b15a Changes synced from sync-manifest.yml
🤖 Keepalive Loop StatusPR #271 | Agent: Codex | Iteration 0/5 Current State
🔍 Failure Classification| Error type | infrastructure | |
Keepalive Work Log (click to expand)
|
There was a problem hiding this comment.
Pull request overview
Syncs GitHub Actions workflow templates and keepalive loop logic from the upstream workflows repository, updating automation behavior for agent orchestration and progress tracking.
Changes:
- Adds the
progress-reviewjob as a dependency of the keepalivesummaryjob. - Improves auto-pilot belt-dispatch reliability by retrying dispatches and attempting re-dispatch during branch-creation backoff.
- Updates keepalive loop summary logic to reset
rounds_without_task_completionafter areviewaction.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| .github/workflows/agents-keepalive-loop.yml | Wires progress-review into the keepalive workflow’s summary stage. |
| .github/workflows/agents-auto-pilot.yml | Adds dispatch retry/verification logic and re-dispatch checks during branch creation backoff. |
| .github/scripts/keepalive_loop.js | Resets the “no progress rounds” counter after a review to allow the agent to run next iteration. |
| needs: | ||
| - evaluate | ||
| - run-codex | ||
| - run-claude | ||
| - progress-review |
There was a problem hiding this comment.
summary now declares needs: progress-review, but progress-review only runs when needs.evaluate.outputs.action == 'review'. When the action is run/fix/conflict, progress-review will be skipped and GitHub will skip summary as well (job-level if: always() does not override a skipped dependency). This will prevent keepalive summaries/state updates on normal agent runs. Make progress-review always complete successfully (move the conditional to steps) or remove it from summary.needs and fetch review outputs conditionally.
| const recentRuns = runs.workflow_runs.filter( | ||
| r => new Date(r.created_at) >= dispatchedAt | ||
| ); |
There was a problem hiding this comment.
The post-dispatch verification uses created_at >= dispatchedAt (runner clock) and only checks for any queued/in_progress run. This can produce false negatives (clock skew or GitHub timestamp lag) and false positives (matching a different workflow run created after dispatchedAt). Filter more defensively (e.g., allow a small negative skew window and require event == 'workflow_dispatch' and head_branch == baseBranch), so dispatchSucceeded reflects the run you just dispatched.
| const recentRuns = runs.workflow_runs.filter( | |
| r => new Date(r.created_at) >= dispatchedAt | |
| ); | |
| const skewMs = 5000; // allow small negative skew / timestamp lag | |
| const skewedDispatchedAt = new Date(dispatchedAt.getTime() - skewMs); | |
| const baseBranch = | |
| (context.payload.pull_request && context.payload.pull_request.base && context.payload.pull_request.base.ref) || | |
| (context.ref ? context.ref.replace('refs/heads/', '') : 'main'); | |
| const recentRuns = runs.workflow_runs.filter(r => { | |
| const createdAt = new Date(r.created_at); | |
| const createdAfterDispatch = createdAt >= skewedDispatchedAt; | |
| const isWorkflowDispatch = r.event === 'workflow_dispatch'; | |
| const matchesBranch = r.head_branch === baseBranch; | |
| return createdAfterDispatch && isWorkflowDispatch && matchesBranch; | |
| }); |
| const { data: runs } = await withRetry((client) => | ||
| client.rest.actions.listWorkflowRuns({ | ||
| owner: context.repo.owner, | ||
| repo: context.repo.repo, | ||
| workflow_id: 'agents-71-codex-belt-dispatcher.yml', | ||
| per_page: 10, | ||
| }) | ||
| ); | ||
| const cutoff = new Date(Date.now() - 30 * 60 * 1000); | ||
| const recentRuns = runs.workflow_runs.filter( | ||
| r => new Date(r.created_at) >= cutoff | ||
| ); | ||
| const alive = recentRuns.find( | ||
| r => r.status === 'queued' || r.status === 'in_progress' | ||
| ); |
There was a problem hiding this comment.
The re-dispatch guard treats any recent belt-dispatcher run in queued/in_progress as “alive”, without confirming it corresponds to this issue/dispatch (no event/head_branch/time correlation). If another issue has an active dispatcher run, this issue may never re-dispatch and will keep backing off. Tighten the “alive” check (at least event === 'workflow_dispatch' and expected ref/branch) or incorporate issue-specific correlation before skipping re-dispatch.
Sync Summary
Files Updated
Files Skipped
Review Checklist
Source: stranske/Workflows
Manifest:
.github/sync-manifest.yml