fix(gateway): deliver targeted exec-event wakes when heartbeat.every is disabled by xinhuagu · Pull Request #79869 · openclaw/openclaw

xinhuagu · 2026-05-09T15:44:05Z

Summary

allow targeted exec-event heartbeat wakes to run even when heartbeat.every resolves disabled (0m)
keep ordinary disabled heartbeats disabled by limiting the bypass to targeted exec-event wakes
add regression coverage for both scheduler dispatch and runHeartbeatOnce

Problem

Issue #62505 reports that coding-agent/background work can appear to never complete. One narrow cause is that background exec completion already enqueues an exec-event wake, but heartbeat dispatch drops it when heartbeat.every is disabled. That blocks the one-shot completion wake even though it is not a periodic heartbeat run.

Changes

in src/infra/heartbeat-runner.ts
- allow runHeartbeatOnce(...) to proceed for exec-event wakes when the interval is otherwise disabled
- allow targeted/session-scoped exec-event wakes through the runner even when no interval-backed agent state exists
add focused regression tests in:
- src/infra/heartbeat-runner.scheduler.test.ts
- src/infra/heartbeat-runner.returns-default-unset.test.ts

Testing

pnpm exec oxlint src/infra/heartbeat-runner.ts src/infra/heartbeat-runner.scheduler.test.ts src/infra/heartbeat-runner.returns-default-unset.test.ts
attempted focused Vitest, but the repo-local test harness is currently failing in this environment before these tests execute:
- test/non-isolated-runner.ts throws Class extends value undefined is not a constructor or null

Closes #62505

…is disabled

clawsweeper · 2026-05-09T15:47:18Z

Thanks for the context here. I swept through the related work, and this is now duplicate or superseded.

Keep open: current main still has the source-level disabled-heartbeat exec completion gap, but this PR is not merge-ready because it overrides an explicit delivery opt-out, can strand deferred zero-interval exec wakes, lacks real behavior proof, and is currently conflicting with main.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #62505
Summary: This PR is the open fix candidate for the canonical disabled-heartbeat background exec completion issue; related PRs address adjacent origin delivery or exec visibility but do not replace this exact wake dispatch problem.

Members:

canonical: [Bug]: Coding Agent never completes anything (worked in 2026.4.2 and earlier) #62505 - The PR body uses closing syntax for this issue and directly changes disabled-interval exec-event wake handling.
superseded: fix(heartbeat): deliver exec events with disabled heartbeat interval #67913 - The earlier closed PR targeted the same disabled-heartbeat exec-event problem but was closed unmerged and does not replace the current review target.
partial_overlap: fix(cron): capture originating session/agent on the cron wake tool call #83738 - The merged PR fixed origin-aware cron wake routing and explicit target-none origin behavior, not disabled-interval exec completion wakes.
partial_overlap: fix(agents): deliver background exec completion to agent via [OpenClaw exec completion] #91921 - The open PR improves background exec completion visibility once a turn runs, but it does not fix scheduler dispatch when the heartbeat interval is disabled.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Canonical path: Close this stale PR. The latest review rated it F, the branch still lacks merge-ready proof, and there has been no human follow-up after the durable review.

So I’m closing this here because the remaining work is already tracked in the canonical issue.

Review details

Best possible solution:

Close this stale PR. The latest review rated it F, the branch still lacks merge-ready proof, and there has been no human follow-up after the durable review.

Do we have a high-confidence way to reproduce the issue?

Yes at source level: current main skips heartbeat execution when heartbeat.every resolves to 0m, while background exec completion still enqueues an exec-event wake. I did not run a live gateway scenario in this read-only review.

Is this the best way to solve the issue?

No. The runner boundary is plausible, but this implementation should preserve outbound delivery authorization separately from exec completion visibility and give fallback cooldown deferrals retry ownership.

Security review:

Security review needs attention: The diff can expose sensitive background command output by overriding an explicit heartbeat delivery opt-out.

[medium] Target none can be bypassed for command output — src/infra/heartbeat-runner.ts:1315
The PR turns explicit heartbeat delivery suppression into target: "last" for origin-carrying zero-interval exec events, which can send background command output to a channel that current main suppresses.
Confidence: 0.9

AGENTS.md: found and applied where relevant.

What I checked:

stale F-rated PR: PR was opened 2026-05-09T15:44:05Z, is older than 60 days, and the latest review rated it F.
proof blocker: real behavior proof is missing and proof tier is F, so this branch is not merge-ready without contributor follow-up.
no human follow-up: live comments and timeline hydrated by apply contain no non-automation activity after the ClawSweeper review.

Likely related people:

steipete: Recent commits on heartbeat scheduler deferrals, heartbeat timeouts, exec runtime documentation, and adjacent heartbeat-runner behavior make this a strong routing candidate. (role: recent heartbeat scheduler contributor; confidence: high; commits: bbc4bee7a22b, 31169ff3b436, 045145c70082; files: src/infra/heartbeat-runner.ts, src/agents/bash-tools.exec-runtime.ts, docs/gateway/background-process.md)
anagnorisis2peripeteia: Merged origin-aware cron wake routing established the current origin delivery behavior while preserving explicit target: none as an opt-out. (role: adjacent origin-delivery contributor; confidence: medium; commits: f1f00cbf1d58; files: src/infra/outbound/targets.ts, src/cron/service/wake.ts, src/gateway/server-cron.ts)
zhangguiping-xydt: Recent heartbeat admission and busy-retry work is directly adjacent to the zero-interval fallback retry ownership question. (role: recent heartbeat admission/retry contributor; confidence: medium; commits: 2196ea29304a; files: src/infra/heartbeat-runner.ts)
agocs: Recent heartbeat delivery cleanup changed pending-final and send-success bookkeeping in the same runner path reviewed here. (role: recent heartbeat delivery-state contributor; confidence: medium; commits: 305fa9c4ddbe; files: src/infra/heartbeat-runner.ts)

Codex review notes: model internal, reasoning high; reviewed against 2c7e989686ba.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 078830765f

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-05-09T15:47:47Z

+          return await runOnce({
+            cfg: state.cfg,
+            agentId: targetAgentId,
+            heartbeat: resolveRequestedHeartbeat(resolveHeartbeatConfig(state.cfg, targetAgentId)),


Preserve exec-event cooldown when every is 0m

When a targeted exec-event wake arrives for an agent whose heartbeat.every is 0m, state.agents has no HeartbeatAgentState, so this new fallback calls runOnce directly and skips the evaluateWakeDeferral/recordRunBookkeeping path used by normal targeted exec wakes. That reopens the runaway case documented in heartbeat-cooldown.ts and the scheduler regression test: repeated background process exits for the same session can invoke a fresh heartbeat/model run every time instead of respecting the min-spacing/flood guard, specifically for users who disable interval heartbeats but still want exec-event delivery.

Useful? React with 👍 / 👎.

…t.every is disabled

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e7576ebf33

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-05-09T20:26:43Z

+          const deferral = evaluateWakeDeferral(fallbackAgent, now, reason, intent);
+          if (deferral.defer) {
+            return { status: "skipped", reason: deferral.reason };


Requeue deferred zero-interval exec events

When heartbeat.every is 0m, this new fallback state is not in state.agents, so a second targeted exec-event that arrives within the 30s cooldown returns skipped/not-due here but is never retried: heartbeat-wake.ts:229-240 only requeues retryable busy reasons, and scheduleNext() still returns early when state.agents.size === 0. In the common case of two background execs finishing close together, the later system event stays queued indefinitely unless some unrelated wake happens after the cooldown.

Useful? React with 👍 / 👎.

The cron `wake` MCP tool currently forwards only `{mode, text}` to the gateway. Every wake then enqueues a system event with no sessionKey / agentId, so the cron service falls back to the heartbeat / main default. Wakes scheduled from a non-main session (Telegram thread, Discord channel, multi-agent setup) silently route to the wrong conversation lane — and on CLI runtimes the woken session burns tokens generating output that no caller can route back. Origin capture (closes the upstream half of openclaw#46886 and openclaw#64556): - `src/agents/tools/cron-tool.ts` — the `wake` case now resolves `opts.agentSessionKey` through `resolveInternalSessionKey` and `resolveSessionAgentId`, matching the existing `add` action at L569-583. Explicit `sessionKey` / `agentId` params on the tool call take precedence over the inferred values so cross-session wakes remain expressible. - `src/gateway/protocol/schema/agent.ts` — `WakeParamsSchema` now declares optional `sessionKey` and `agentId` (NonEmptyString) so the gateway-level validator types them explicitly. The schema's `additionalProperties: true` continues to accept forward-compat metadata unchanged. - `src/gateway/server-methods/cron.ts` — the wake handler reads both fields, trims them, and forwards to `context.cron.wake`. - `src/cron/service.ts` + `src/cron/service/ops.ts` + `src/cron/service/timer.ts` — `wake()` accepts optional `sessionKey`/`agentId` and threads them into `enqueueSystemEvent` and `requestHeartbeatNow`. Missing / whitespace-only fields fall through to the dep's default so pre-existing call sites with no origin keep behaving the same way (backwards compatible). Tests: - `src/cron/service/wake-origin.test.ts` (new, 6 tests) — direct seams on `wake()`: origin forwarded on `mode: "now"`, queued on `mode: "next-heartbeat"`, default fallback when origin omitted, whitespace-only origin treated as omitted, empty text still rejected. - `src/gateway/protocol/index.test.ts` — extends `validateWakeParams` coverage with the new optional fields accepted + empty-string rejected. Out of scope (deliberate split): - Channel/thread/topic capture on the job's `delivery` block — follow-up PR once this contract lands. The minimum-viable fix here is session routing, which unblocks the CLI runtime's `--resume <session>` path and the embedded session-resolution path without a schema rewrite of the delivery contract. - The 5 stalled wake-related PRs (openclaw#70268, openclaw#57199, openclaw#82767, openclaw#79869, openclaw#63096) each fix downstream specifics. This PR fixes the upstream origin-capture they all silently assume.

openclaw-barnacle · 2026-05-29T04:48:43Z

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

openclaw-barnacle · 2026-07-23T04:27:39Z

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

fix(gateway): deliver targeted exec-event wakes when heartbeat.every …

0788307

…is disabled

openclaw-barnacle Bot added size: S triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. labels May 9, 2026

chatgpt-codex-connector Bot reviewed May 9, 2026

View reviewed changes

fix(gateway): preserve exec-event delivery and cooldown when heartbea…

e7576eb

…t.every is disabled

openclaw-barnacle Bot added size: M and removed size: S labels May 9, 2026

chatgpt-codex-connector Bot reviewed May 9, 2026

View reviewed changes

clawsweeper Bot mentioned this pull request May 12, 2026

[Bug]: Coding Agent never completes anything (worked in 2026.4.2 and earlier) #62505

Open

anagnorisis2peripeteia mentioned this pull request May 18, 2026

fix(cron): capture originating session/agent on the cron wake tool call #83738

Merged

openclaw-barnacle Bot added the stale Marked as stale due to inactivity label May 29, 2026

openclaw-barnacle Bot removed the stale Marked as stale due to inactivity label Jun 1, 2026

openclaw-barnacle Bot added stale Marked as stale due to inactivity triage: needs-pr-context Candidate: external PR body lacks required problem context or evidence. and removed stale Marked as stale due to inactivity labels Jul 23, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(gateway): deliver targeted exec-event wakes when heartbeat.every is disabled#79869

fix(gateway): deliver targeted exec-event wakes when heartbeat.every is disabled#79869
xinhuagu wants to merge 2 commits into
openclaw:mainfrom
xinhuagu:fix/62505-exec-event-zero-interval

xinhuagu commented May 9, 2026

Uh oh!

clawsweeper Bot commented May 9, 2026 •

edited

Loading

Uh oh!

chatgpt-codex-connector Bot left a comment

Uh oh!

chatgpt-codex-connector Bot May 9, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Uh oh!

chatgpt-codex-connector Bot May 9, 2026

Uh oh!

openclaw-barnacle Bot commented May 29, 2026

Uh oh!

openclaw-barnacle Bot commented Jul 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

xinhuagu commented May 9, 2026

Summary

Problem

Changes

Testing

Uh oh!

clawsweeper Bot commented May 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot May 9, 2026

Choose a reason for hiding this comment

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot May 9, 2026

Choose a reason for hiding this comment

Uh oh!

openclaw-barnacle Bot commented May 29, 2026

Uh oh!

openclaw-barnacle Bot commented Jul 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

clawsweeper Bot commented May 9, 2026 •

edited

Loading