openclaw - 💡(How to fix) Fix [Bug]: qmd update/embed no longer being triggered after upgrading to 2026.5.4 [1 comments, 2 participants]

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After upgrading to 2026.5.4, qmd auto update/embed stopped working and never triggers either on interval or on boot.

Steps to reproduce

qmd configuration: "memory": { "backend": "qmd", "qmd": { "searchMode": "query", "includeDefaultMemory": true, "update": { "onBoot": true, "interval": "5m", "embedInterval": "5m" }, "sessions": { "enabled": true }, "limits": { "maxResults": 10, "timeoutMs": 50000 }, "mcporter": { "enabled": true, "serverName": "qmd", "startDaemon": true } } }

Expected behavior

Before this update, qmd was able to automatically update and embed.

Actual behavior

As long as I don't manually trigger update, qmd index will always remain out-dated.

OpenClaw version

2026.5.4

Operating system

Windows 11 WSL2

Install method

No response

Model

minimax-m2.7

Provider / routing chain

openclaw->tencent-token-plan->minimax-m2.7

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Analysis by Minimax:

What the restart log shows:

Gateway fully reloaded with new binary at 09:29:40 ✅
Cron module started (zero user jobs — that's fine, QMD updates aren't cron jobs)
But: no QMD update or embed has fired since the restart — not at 09:34:40 (5 min mark), not at any subsequent interval
What I checked:

update.onBoot: true + update.interval: "5m" + update.embedInterval: "5m" — all present in config ✅
The config change was detected and accepted (config change detected; evaluating reload → accepted) ✅
After restart, the new binary is running 2026.5.4 ✅
openclaw memory status still shows Dirty: no and lastUpdateAt: null — QMD hasn't been triggered since restart ❌
Likely cause: defect in 2026.5.4 where memory.qmd.update.interval is recognized and accepted but the internal scheduler never actually fires the periodic QMD update. The reload logic sees the config change, but the subsystem that schedules the recurring work doesn't initialize correctly on this build.

Impact and severity

memory is no long reliable unless I manually update the index.

Additional information

No response