Summary
When using the withMemWal middleware with autoSave: true, memory persistence appeared inconsistent across separate script executions — the same type of interaction sometimes resulted in the fact being recallable in a later run, and sometimes not, with no errors thrown in either case.
Environment
ai@7.0.15@mysten-incubation/memwal/ai (withMemWal)@ai-sdk/openai, model: gpt-4o-mini- Node.js v22.19.0, Windows
What happened
Using this pattern:
const model = withMemWal(openai("gpt-4o-mini"), {
key: process.env.MEMWAL_PRIVATE_KEY!,
accountId: process.env.MEMWAL_ACCOUNT_ID!,
serverUrl: process.env.MEMWAL_SERVER_URL,
namespace: "chatbot-prod",
maxMemories: 5,
autoSave: true,
});I ran the script once, stating a fact ("My name is Alex and I'm building a football stats agent"). In a subsequent, completely separate process run, asking "What do you know about me?" sometimes correctly recalled the fact, and sometimes returned no information at all — with identical code and no errors logged in either case.
Suspected root cause
autoSave appears to persist memories asynchronously in the background rather than blocking until the write is confirmed. Since each test run was a short-lived CLI script, the Node process likely exited before the background save completed in the "failed" runs — silently dropping the memory with no error surfaced to the caller.
By contrast, switching to explicit memwal.remember() + memwal.waitForRememberJob() calls (bypassing the withMemWal middleware entirely) produced 100% consistent, reliable results in the same script structure.
Suggestion
- Document that
autoSave is fire-and-forget and may not complete before a short-lived process exits, with a recommendation to use explicit remember() + waitForRememberJob() for CLI/script contexts where the process may exit quickly
- Consider exposing a way to flush/await pending
autoSave writes before process exit (e.g. a memwal.flush() or similar), since long-running server processes wouldn't have this issue but short scripts do
- Alternatively, surface a warning/log when a process exits with pending unsaved
autoSave writes
Impact
This was confusing to diagnose since there were no errors — the memory simply wasn't there sometimes, which looked like a recall/search issue rather than a write-timing issue, until directly comparing against the explicit remember/wait pattern.
Summary
When using the
withMemWalmiddleware withautoSave: true, memory persistence appeared inconsistent across separate script executions — the same type of interaction sometimes resulted in the fact being recallable in a later run, and sometimes not, with no errors thrown in either case.Environment
ai@7.0.15@mysten-incubation/memwal/ai(withMemWal)@ai-sdk/openai, model: gpt-4o-miniWhat happened
Using this pattern:
I ran the script once, stating a fact ("My name is Alex and I'm building a football stats agent"). In a subsequent, completely separate process run, asking "What do you know about me?" sometimes correctly recalled the fact, and sometimes returned no information at all — with identical code and no errors logged in either case.
Suspected root cause
autoSaveappears to persist memories asynchronously in the background rather than blocking until the write is confirmed. Since each test run was a short-lived CLI script, the Node process likely exited before the background save completed in the "failed" runs — silently dropping the memory with no error surfaced to the caller.By contrast, switching to explicit
memwal.remember()+memwal.waitForRememberJob()calls (bypassing thewithMemWalmiddleware entirely) produced 100% consistent, reliable results in the same script structure.Suggestion
autoSaveis fire-and-forget and may not complete before a short-lived process exits, with a recommendation to use explicitremember()+waitForRememberJob()for CLI/script contexts where the process may exit quicklyautoSavewrites before process exit (e.g. amemwal.flush()or similar), since long-running server processes wouldn't have this issue but short scripts doautoSavewritesImpact
This was confusing to diagnose since there were no errors — the memory simply wasn't there sometimes, which looked like a recall/search issue rather than a write-timing issue, until directly comparing against the explicit remember/wait pattern.