M043_quarantine_display_summaries migration shows complete in migration_log but health check reports failure

[unfall103-debug]

---

Description:

After upgrading to v4.0.10, the daemon health check consistently reports migration_failures: ["M043_quarantine_display_summaries"] and the service never enters the ready state.

Steps to reproduce:

1. Run slm db migrate --status — shows M043_quarantine_display_summaries: complete
2. Query migration_log table — status is also complete
3. Check /health endpoint — migrations: false, migration_failures contains M043_quarantine_display_summaries

Expected behavior:

When a migration is complete in migration_log, the health check should report migrations: true and the service should enter ready state.

Actual behavior:

The migration has clearly succeeded (confirmed both by slm db migrate --status and direct database query), but the health check falsely reports it as failed, keeping the service perpetually in not_ready state.

Environment:

• Version: superlocalmemory 4.0.10
• Database path: /root/.superlocalmemory/memory.db
• Deployment: systemd service
• OS: Ubuntu / Debian

Additional context:

• migration_log query result:

  M043_quarantine_display_summaries|complete|2026-08-22T16:25:46.767075+00:00
  

• /health output (key fields):

  "ready": false,
  "readiness": {
    "migrations": false,
    "migration_failures": ["M043_quarantine_display_summaries"]
  }

• slm db migrate reports: Applied=0 Skipped=24 Failed=0
• slm db migrate --status shows M043 as complete
• systemctl restart slm does not resolve the issue
• Clearing cache/state files (*.pid, *.sock, *.lock, *.db-shm, *.db-wal) does not resolve the issue

Suspected cause:

The health check logic appears to be reading from a separate failure marker (not migration_log) that is not being cleared when the migration actually succeeds. This may be a bug in the v4.0.10 migration verification logic.

---

[varun369]

v4.1.0 is out and makes this diagnosable. It does not yet fix whatever is wrong with your store, so I am leaving this open.

What is actually happening — your suspected cause is not it

There is no separate failure marker. migration_log and the health check are answering two different questions:

• migration_log records what was done.
• A migration recorded complete is re-checked by its own verify() on every daemon start — that asks whether what was done still holds.

When those diverge, the log correctly says complete and health correctly says failed. Neither is lying, and nothing anywhere told you they were different questions. That is the bug I can fix, and did.

For M043 specifically, verify() is a standing guard over data, not just schema. When it returns False the runner calls repair() and re-checks; if it still fails, the migration is reported failed for that start — with the log still reading complete. That is your exact symptom, including slm db migrate reporting Failed=0, because --status only ever printed the log.

What 4.1.0 adds

/health now carries the reason, not just the name:

"migration_failures": ["M043_quarantine_display_summaries"],
"migration_failure_reasons": {
  "M043_quarantine_display_summaries": "safe repair did not restore M043_quarantine_display_summaries"
}

and slm db migrate --status marks the divergence instead of reprinting the log:

  M043_quarantine_display_summaries: complete  <- recorded complete, end-state no longer holds

Why upgrading may fix it outright

An hour ago I upgraded my own machine to 4.1.0 and hit the same shape of problem on a different migration. M047 had been recorded complete, but its conversion had stopped part-way: 3,850 rows converted, 32 left in the old format. Those 32 were enough to break every recall with a utf-8 codec can not decode byte error, and /health showed recall_health: false. Starting 4.1.0 re-ran the verification, finished the conversion, and recall went from HTTP 500 on every query to working — data fully intact.

Your M043 may be the same thing: a completed migration whose end-state stopped holding, which a newer start can finish.

What would help

Upgrade to 4.1.0 and send:

slm db migrate --status
slm health --json | python3 -c "import json,sys; print(json.load(sys.stdin)['readiness'])"

The second one now names the condition that is failing. With that I can tell you whether it is repairable in place or needs a targeted fix.

Thank you for the report — the migration_log query and the /health output side by side are what made the two-different-questions problem obvious.

[unfall103-debug]

---

Subject: Upgraded to 4.1.0 but M043 issue still persists

I upgraded to 4.1.0 as suggested, but the issue remains.

Steps I took:

1. Upgraded to 4.1.0:

   superlocalmemory 4.1.0
   

2. Ran slm db migrate --status – M043 is still marked complete but end-state no longer holds:

   M043_quarantine_display_summaries: complete  <- recorded complete, end-state no longer holds
   

3. Ran slm db migrate – output:

   Applied=0 Skipped=25 Failed=0
   

4. Checked /health endpoint – still failing:

   {
     "ready": false,
     "readiness": {
       "migrations": false,
       "migration_failures": ["M043_quarantine_display_summaries"],
       "migration_failure_reasons": {
         "M043_quarantine_display_summaries": "safe repair did not restore M043_quarantine_display_summaries"
       }
     }
   }

So the automatic safe repair in 4.1.0 did not restore the end-state for M043. Could you please advise on the next steps or provide a targeted fix for this specific migration?

Thank you.

---

[varun369]

Thank you — that output is exactly what was needed, and the new fields did their job: we now know repair() ran and verify() still refused, which is a much narrower problem than where we started.

Two things I owe you: what I found on my own machine, and a script that will name the specific check that is failing on yours.

First, an important correction to how bad this is

I said 4.1.0 makes it diagnosable. I should also have said that a flagged migration makes the daemon return 503 on every feature route — only health, status and repair paths stay reachable. So this is not a cosmetic status for you, it is an outage, and there is no bypass flag. I am treating it that way.

What I found on my own store

Running M043's verify() directly here, on a healthy-looking 4.1.1 daemon that reports migrations: true:

check 3  summaries not withheld        0   (must be 0)
check 4  withheld with no display copy 0   (must be 0)
check 5  memories wrongly hidden       1   (must be 0)
verify() overall -> False

So my store fails verify() too — and /health still says migrations: true, because that field is a snapshot taken at startup. The condition re-appeared after boot. On my store repair() clears it (1 → 0, verify False → True). Yours reports that repair did not, so your failing check is a different one, and M043 has five.

The script — please run this

It is read-only and prints each check separately.

curl -sO https://raw.githubusercontent.com/qualixar/superlocalmemory/main/scripts/diagnose_m043.py
python3 diagnose_m043.py

Or if you would rather not download anything, scripts/diagnose_m043.py is in the repo at the v4.1.1 tag — read it first, it opens the database mode=ro and writes nothing.

It also prints two paths. Please check they match, because one line in your report does not add up: slm db migrate said Applied=0 Skipped=25 Failed=0 while the daemon says M043 failed. Same function, so if both were looking at the same file they could not disagree. You are on systemd as root — if the unit's HOME differs from your shell's, your CLI has been repairing one store while the daemon keeps failing on another, and that alone would explain everything you have seen. The script prints HOME, the store it checked, and the store the CLI would use.

Then

Send me the script's output. If it names a check, I will write the targeted repair for that condition and ship it. If the paths differ, the fix is much simpler than a code change.

Either way, I am also going to make two changes regardless of what your store says, because both are wrong independently of it:

1. verify() should report which invariant failed, not just that repair did not restore it. "safe repair did not restore M043" sent you back here to ask, which is the same gap I fixed one level up in 4.1.0 and did not fix one level down.
2. A migration whose check a normal consolidation pass can re-violate should not be able to 503 the whole daemon indefinitely. My own store demonstrates the condition recurring after startup. That design is wrong and I would rather say so than defend it.

Apologies for the runaround. 4.1.1 is out with an unrelated upgrade fix; neither release addresses your store yet, and I am not going to claim otherwise until your output says which check it is.

[unfall103-debug]

---

I've reset the database and the issue is resolved on my end.

A few reasons why I went this route:

1. SLM is not directly integrated with OpenClaw — my agent is OpenClaw, and all memories are synced via scripts. Many features in SLM aren't really usable for my workflow right now, so SLM isn't my primary memory backend.

2. There were too many upgrades (3.x → 4.x) and the migration issues kept piling up. Resetting was the cleanest way to get a working system again.

Thanks for your help and for the diagnostic script — I appreciate the detailed responses. Since I've wiped the database, I'm closing this issue. Feel free to close it on your side as well.

---

[varun369]

Fix shipped in v4.1.2 — on PyPI and npm now.

Two changes, and the second one is the one that unblocks you.

1. The reason now names the condition

safe repair did not restore M043_quarantine_display_summaries told you the step and not which of its five checks had failed. It now says which, e.g.

"migration_failure_reasons": {
  "M043_quarantine_display_summaries":
    "safe repair did not restore M043_quarantine_display_summaries: 1 real memories are hidden from recall and should not be"
}

2. A data check no longer makes the store unreachable

This is the part I got wrong, and it is worth saying plainly rather than burying.

Any failed step returned 503 on every route except health and status. For a missing table that is correct — the queries would hit something that is not there. But three of M043's five checks are about data, not structure, and ordinary use can re-violate them: a single background consolidation pass hiding one more memory is enough. So one drifted row could take a working store offline indefinitely, and the restart people reached for could not fix it, because there was nothing structurally wrong to fix.

I can be specific about how ordinary that is: my own machine fails the same check right now, on a healthy 4.1.2 daemon that serves every request normally. The condition reappeared after boot. A quality check that recurs in normal use should never have been able to hold the whole daemon down.

From 4.1.2, a migration declares which kind of failure it has. Structural failures still refuse to serve. A drifted data check reports itself, keeps serving, and gets repaired in the background. Anything that does not declare stays refusing, so nothing became more permissive by accident.

What to do

pipx upgrade superlocalmemory   # or: pip install --upgrade superlocalmemory
slm restart
curl -s http://127.0.0.1:8765/health | python3 -m json.tool

You should get ready: true with the store serving, and the drifted check named under migration_failure_reasons with migration_blocking: [] beside it — reported, not blocking.

If it is still ready: false, then migration_blocking will name what is genuinely structural, and scripts/diagnose_m043.py will name the check. Send me either and I will take it from there.

Also worth checking

The path question from my last comment still stands and is quick: slm db migrate reported Applied=0 Skipped=25 Failed=0 while the daemon reported a failure. If your systemd unit's HOME differs from your shell's, those two commands were looking at different files the whole time. scripts/diagnose_m043.py prints both paths.

Thank you for staying with this. The 503-on-a-data-check design was wrong, you are the reason it got found, and it would not have been fixed from the inside.