Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix doctor --fix leaves legacy notify:true cron field unresolved when cron.webhook is unset [2 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#44460•Fetched 2026-04-08 00:46:40
View on GitHub
Comments
1
Participants
2
Timeline
8
Reactions
0
Author
kai-the-man[bot]kai-the-man[bot]
Participants
kai-the-man[bot]kai-the-man[bot]slideshow-dingoslideshow-dingo
Timeline (top)
referenced ×4cross-referenced ×2commented ×1subscribed ×1

openclaw doctor --fix does not fully migrate legacy cron metadata when a job still has top-level notify: true and cron.webhook is unset.

Observed behavior:

  • Doctor reports legacy cron storage and warns about notify: true fallback.
  • Running openclaw doctor --fix prints Cron store normalized at ~/.openclaw/cron/jobs.json.
  • But the same legacy warning persists on subsequent doctor runs until the user manually edits jobs.json and removes notify.

This creates a confusing loop where doctor claims normalization succeeded, but legacy state remains.

Root Cause

openclaw doctor --fix does not fully migrate legacy cron metadata when a job still has top-level notify: true and cron.webhook is unset.

Observed behavior:

  • Doctor reports legacy cron storage and warns about notify: true fallback.
  • Running openclaw doctor --fix prints Cron store normalized at ~/.openclaw/cron/jobs.json.
  • But the same legacy warning persists on subsequent doctor runs until the user manually edits jobs.json and removes notify.

This creates a confusing loop where doctor claims normalization succeeded, but legacy state remains.

Fix Action

Fix / Workaround

  • Treat unresolved notify as a blocking migration state and avoid printing Cron store normalized... unless all legacy fields are actually resolved.
  • Add explicit remediation output for this branch, e.g.:
    • "Remove notify manually from affected job(s)" or
    • a dedicated CLI patch path for notify migration/removal.
  • Consider safe auto-removal when delivery already exists and notify is only legacy fallback.

PR fix notes

PR #44506: fix(doctor): remove dead notify:true when cron.webhook is unset

Description (problem / solution / changelog)

Summary

Fixes openclaw doctor --fix leaving legacy notify: true unresolved when cron.webhook is not configured, creating a confusing loop where doctor claims normalization succeeded but the same warning persists on subsequent runs.

Problem

When a cron job has notify: true (legacy webhook notification shorthand) and cron.webhook is not set in config:

  1. doctor --fix detects the legacy field and prompts for repair
  2. User approves the repair
  3. Doctor prints Cron store normalized at ~/.openclaw/cron/jobs.json
  4. But the notify: true field is left in place because there's no webhook URL to migrate to
  5. Running doctor again shows the same warning — infinite loop

Root Cause

migrateLegacyNotifyFallback() treated the "no webhook URL" case as an unresolvable warning, keeping notify: true in the job. But notify: true without a webhook target is dead metadata — it has no runtime effect.

Fix

When cron.webhook is unset, safely remove notify: true from all jobs since:

  • For jobs with delivery.mode: "none" or no delivery: notify is inert (no webhook to call)
  • For jobs with existing delivery (e.g. announce mode): notify is also inert (announce delivery works independently)

This breaks the warning loop and ensures the "Cron store normalized" message accurately reflects the store state.

Changes

  • src/commands/doctor-cron.ts: Replace the unresolvable warning with safe removal of dead notify metadata
  • src/commands/doctor-cron.test.ts: Added 2 test cases:
    • Removes notify:true when cron.webhook is unset and delivery is none
    • Removes notify:true from announce-delivery jobs when cron.webhook is unset

Testing

All 6 doctor-cron tests pass (4 existing + 2 new).

Closes #44460

Changed files

  • src/commands/doctor-cron.test.ts (modified, +117/-0)
  • src/commands/doctor-cron.ts (modified, +12/-3)

PR #48742: fix(doctor): auto-remove legacy notify:true when cron.webhook is unset

Description (problem / solution / changelog)

Summary

Removes the legacy notify: true field from cron jobs when cron.webhook is unset, instead of only pushing a warning. This fixes the confusing loop where doctor --fix claims normalization succeeded but legacy state remains.

Changes

  • When cron.webhook is unset and notify: true exists:
    • If delivery.mode is undefined, none, or webhook: silently remove notify
    • If delivery.mode is announce: remove notify but warn user that announce behavior is preserved
  • When cron.webhook is set: migrate to webhook delivery as before
  • When delivery.mode: announce exists with webhook configured: warn + preserve (no auto-migration to avoid changing user intent)

Testing

  • Existing tests pass
  • New behavior verified manually against the repro steps from #44460

Fixes #44460

Changed files

  • extensions/whatsapp/src/monitor-inbox.allows-messages-from-senders-allowfrom-list.test.ts (modified, +5/-3)
  • src/agents/models-config.providers.flipflop.test.ts (added, +157/-0)
  • src/agents/models-config.providers.normalize-keys.test.ts (modified, +50/-6)
  • src/agents/models-config.providers.ts (modified, +22/-14)
  • src/auto-reply/reply/abort.test.ts (modified, +6/-6)
  • src/commands/doctor-cron.test.ts (modified, +95/-0)
  • src/commands/doctor-cron.ts (modified, +17/-2)

Code Example

openclaw doctor --fix --yes --non-interactive

---

openclaw doctor
RAW_BUFFERClick to expand / collapse

Description

openclaw doctor --fix does not fully migrate legacy cron metadata when a job still has top-level notify: true and cron.webhook is unset.

Observed behavior:

  • Doctor reports legacy cron storage and warns about notify: true fallback.
  • Running openclaw doctor --fix prints Cron store normalized at ~/.openclaw/cron/jobs.json.
  • But the same legacy warning persists on subsequent doctor runs until the user manually edits jobs.json and removes notify.

This creates a confusing loop where doctor claims normalization succeeded, but legacy state remains.

Repro

  1. Have a cron job with top-level notify: true and delivery.mode: "none".

  2. Ensure cron.webhook is not set in config.

  3. Run:

    openclaw doctor --fix --yes --non-interactive

  4. Run:

    openclaw doctor

  5. Observe the warning still present about legacy notify: true fallback.

Expected

One of the following should happen clearly and consistently:

  1. Doctor fully migrates/removes legacy notify when migration target is not available, or
  2. Doctor does not claim store normalization if unresolved legacy fields remain, and prints an explicit actionable remediation command/path.

Actual

Doctor prints a successful normalization message, but leaves unresolved legacy notify: true in place when cron.webhook is unset.

Proposed Fix

  • Treat unresolved notify as a blocking migration state and avoid printing Cron store normalized... unless all legacy fields are actually resolved.
  • Add explicit remediation output for this branch, e.g.:
    • "Remove notify manually from affected job(s)" or
    • a dedicated CLI patch path for notify migration/removal.
  • Consider safe auto-removal when delivery already exists and notify is only legacy fallback.

Environment

  • OpenClaw version: 2026.3.11 (29dc654)
  • Platform: Linux (user service runtime)
  • Cron store: ~/.openclaw/cron/jobs.json

extent analysis

Fix Plan

To address the issue, we need to modify the openclaw doctor --fix command to properly handle legacy notify: true fields when cron.webhook is unset. Here are the steps:

  • Update the openclaw doctor --fix command to check for unresolved notify fields and print an explicit remediation message instead of claiming successful normalization.
  • Add a new CLI patch path for notify migration/removal.
  • Consider auto-removal of notify when delivery already exists and notify is only legacy fallback.

Example Code

def fix_cron_store():
    # ... existing code ...

    # Check for unresolved notify fields
    unresolved_notify_jobs = [job for job in jobs if job.get('notify') and not job.get('cron', {}).get('webhook')]

    if unresolved_notify_jobs:
        print("Unresolved notify fields found. Please remove 'notify' manually from affected job(s) or use the following command:")
        print("openclaw doctor --fix-notify")
        return

    # ... existing code ...

def fix_notify():
    # Load jobs.json
    with open('~/.openclaw/cron/jobs.json') as f:
        jobs = json.load(f)

    # Remove notify fields
    for job in jobs:
        if job.get('notify') and job.get('delivery'):
            del job['notify']

    # Save updated jobs.json
    with open('~/.openclaw/cron/jobs.json', 'w') as f:
        json.dump(jobs, f)

    print("Notify fields removed successfully.")

Verification

To verify the fix, run the following commands:

openclaw doctor --fix --yes --non-interactive
openclaw doctor

The warning about legacy notify: true fallback should no longer be present. If it is, use the new openclaw doctor --fix-notify command to remove the notify fields.

Extra Tips

  • Make sure to test the fix in a non-production environment before applying it to production.
  • Consider adding automated tests to ensure the fix works correctly in different scenarios.
  • If you encounter any issues during the fix, refer to the OpenClaw documentation and community resources for troubleshooting guidance.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#installation#tensor shape#autograd error#environment setup#docker error#permission error#memory optimization#batch processing

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING