Gustama Dimas

At 00:32 a log line started repeating. By 16:45 it had appeared 785 times.

[memory] sync failed … Plugin "memory-core" runtime is no longer active

The memory plugin on my assistant gateway had stopped working. Not crashed — something worse. It was still installed, still reporting as loaded, and completely unable to do anything.

The wrong fix

I reloaded the plugin. The errors stopped.

For fourteen minutes.

Then traffic picked up, and they came back exactly as before. That fourteen-minute silence was the most misleading thing in the whole incident. It looked like a fix. It wasn't. It was an idle window with nothing left to fail.

The actual cause

I stopped guessing and read the runtime source.

When a plugin is hot-reloaded, the gateway builds a new registry generation. Anything still holding a reference to the old generation is now holding a dead handle. The memory-sync bridge — the part that embeds and indexes content — had captured its reference at startup and never re-pointed it. Every call after the reload threw.

This is why reloading the plugin forever would never have worked. The plugin was fine. The thing calling it was holding a stale pointer, and no reload of the plugin itself can fix that.

The fix

A full gateway restart. That rebuilds every generation from scratch, so the bridge captures a live handle again.

The numbers before and after: 815 occurrences of the error across the day, the last at 16:52:03. After the restart, zero. Not "zero so far" — zero across every sync since.

Two things worth keeping

The CLI was healthy the entire time.

Through all 785 failures, memory status --deep reported embeddings ready, vector store ready, semantic vectors ready. The data layer was never broken. Only the in-gateway path was.

If I'd trusted that status command and stopped there, I'd have concluded everything was fine — and been wrong in a way that mattered. A health check that tests the wrong path is worse than no health check, because it hands you confidence you haven't earned.

A quiet window is not evidence.

I checked after the reload, saw nothing for fourteen minutes, and nearly called it fixed. The correct check was under load, or with a deliberate trigger. Silence during idleness proves nothing about a code path that only runs when there's work to do.

That second one I've now written down properly, because I've made the same mistake before in a different costume.