PR #64329: fix(heartbeat): treat empty heartbeat config ({}) as disabled

• Repository: openclaw/openclaw
• Author: Yanhu007
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/64329

Description (problem / solution / changelog)

Summary

Fixes #64293 — Heartbeats continue running despite heartbeat: {} config, causing ~2M tokens/day burn with zero user activity.

Root Cause

When agents.defaults.heartbeat: {} is set, the empty object {} is truthy in JavaScript. resolveHeartbeatConfig returned it as-is, and resolveHeartbeatIntervalMs then fell through to the default DEFAULT_HEARTBEAT_EVERY = "30m" since {}.every is undefined.

Result: heartbeats ran every 30 minutes even though the user intended to disable them.

Fix

Added isEmptyHeartbeatConfig() helper that detects Object.keys(config).length === 0. When the effective config (after merging defaults and overrides) is an empty object, resolveHeartbeatConfig now returns undefined — which the scheduler correctly interprets as "no heartbeat" and skips scheduling.

Why empty {} = disabled

• Setting heartbeat: {} is the most intuitive way to say "I acknowledge this config key exists but want it off"
• The issue reporter and other users explicitly tried this as an opt-out mechanism
• heartbeat: { every: "0" } and omitting the key entirely already disable heartbeats; {} should be consistent
• Users who want defaults can simply omit the heartbeat key

Changes

• src/infra/heartbeat-runner.ts: resolveHeartbeatConfig returns undefined for empty merged config; new isEmptyHeartbeatConfig helper

Testing

• Empty {} → resolveHeartbeatConfig returns undefined → heartbeat scheduler skips
• { every: "30m" } → works as before (not empty)
• undefined / key omitted → works as before (fallback defaults apply)

Changed files

• src/infra/heartbeat-runner.empty-config-disabled.test.ts (added, +85/-0)
• src/infra/heartbeat-runner.ts (modified, +15/-3)
• src/infra/heartbeat-summary.ts (modified, +16/-3)

PR #64540: fix: treat empty heartbeat config as disabled (closes #64293)

• Repository: openclaw/openclaw
• Author: xchunzhao
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/64540

Description (problem / solution / changelog)

Summary

• Problem: Setting agents.defaults.heartbeat: {} in config does not disable heartbeats — they still fire every 30 minutes, burning ~2M+ input tokens/day with zero user activity.
• Why it matters: Users expect heartbeat: {} to mean "disabled". Silent token burn at ~$6/day (Claude Sonnet 4.5 rates) with no visible indication.
• What changed: Added empty-object detection in isHeartbeatEnabledForAgent and resolveHeartbeatIntervalMs so that heartbeat: {} is treated as disabled instead of falling through to the default 30m interval.
• What did NOT change: Non-empty heartbeat configs (e.g. { every: "1h" }, { prompt: "..." }) are completely unaffected. Default behavior when no heartbeat key is present is also unchanged.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #64293
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: resolveHeartbeatIntervalMs() falls through to DEFAULT_HEARTBEAT_EVERY ("30m") when heartbeat?.every is undefined — which is the case for an empty {} config. Similarly, isHeartbeatEnabledForAgent() returns true for the default agent even when the defaults heartbeat is {}, because it only checks for explicit agent-level heartbeat entries and never inspects the defaults object itself.
• Missing detection / guardrail: No check for empty-object heartbeat config anywhere in the resolution chain.
• Contributing context: Users naturally assume heartbeat: {} means "I acknowledged this config key but want it off" (similar to how cron: {} or memory: {} would imply disabled).

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
• Target test or file: src/infra/heartbeat-summary.test.ts
• Scenario the test should lock in: resolveHeartbeatIntervalMs(cfg, undefined, {}) returns null; isHeartbeatEnabledForAgent(cfg) returns false when defaults heartbeat is {}
• Why this is the smallest reliable guardrail: Pure function, easily testable in isolation
• If no new test is added, why not: Keeping PR minimal — happy to add tests if requested by reviewer

User-visible / Behavior Changes

• agents.defaults.heartbeat: {} now correctly disables heartbeat polling (previously silently ran every 30m)
• Per-agent heartbeat: {} in agents list now correctly disables that agent's heartbeat

Diagram (if applicable)

Before:
heartbeat: {} -> resolveHeartbeatIntervalMs -> falls through to DEFAULT "30m" -> schedules heartbeat

After:
heartbeat: {} -> resolveHeartbeatIntervalMs -> detects empty object -> returns null -> no heartbeat scheduled

Security Impact (required)

• New permissions/capabilities? No
• Auth boundary changes? No
• Secrets/token exposure risk? No
• New external calls? No
• Sandbox/isolation changes? No

Evidence

• Code inspection: traced the full heartbeat resolution chain from config load → resolveHeartbeatConfig → resolveHeartbeatIntervalMs → scheduling
• pnpm check passes (lint + typecheck)
• AI-assisted (Claude): fix authored with AI assistance, manually reviewed and verified

Human Verification (required)

• Verified scenarios: Traced config resolution for heartbeat: {}, heartbeat: { every: "1h" }, and no heartbeat key — confirmed only empty-object case is affected
• Edge cases checked: heartbeat: undefined, heartbeat: null, heartbeat: { every: "0" } — all unaffected by this change
• What you did not verify: Full integration test with running gateway (no Docker setup locally for this)

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes — only changes behavior for the specific {} empty-object case
• Config/env changes? No
• Migration needed? No

Risks and Mitigations

• Risk: Someone intentionally uses heartbeat: {} expecting default 30m behavior
  • Mitigation: This is extremely unlikely — {} universally signals "empty/disabled" in config conventions. Users wanting defaults would simply omit the key.

Changed files

• src/infra/heartbeat-summary.ts (modified, +21/-2)