OpenClaw Accepted Our PR #76024: A Windows EBUSY Fix That Made It Upstream

A Small Fix, But a Real Upstream Loop

PR #76024 is not a grand story about making OpenClaw fully stable on Windows.

It is smaller, and that is why it is useful.

The PR fixed one concrete boundary in OpenClaw: during memory atomic reindex on Windows, the file swap step can briefly fail when fs.rename hits a transient file lock. The error may appear as EBUSY, EPERM, or EACCES.

That kind of Windows failure is annoying because it is often timing-dependent. It may happen on one machine and disappear on another. It may fail once, then pass on the next run. If you turn it into a broad rewrite, you risk changing behavior far outside the real problem.

So the fix stayed narrow.

What Was Fixed

OpenClaw’s memory atomic reindex flow builds a new SQLite index and then swaps a group of files into place.

On Windows, another process can briefly hold one of those files. That process may be the runtime, a scanner, an indexer, or something else touching the filesystem at the wrong moment.

The patch did not change the whole storage layer. It did not change global SQLite settings. It did not try to solve every Windows stability issue.

It only handled the transient file swap boundary:

memory atomic reindex
-> index file swap
-> transient fs.rename failure
-> EBUSY / EPERM / EACCES
-> bounded retry

In plain terms: if Windows briefly says “this file is busy” during the swap, OpenClaw now gets a short retry window instead of immediately failing the whole reindex path.

The Patch Strategy

The PR title was:

fix(memory): retry transient index swaps on Windows

The key decision was to keep the retry small and local.

• retry only transient file-swap errors: EBUSY, EPERM, EACCES
• keep the retry budget limited
• preserve the existing missing-sidecar behavior
• do not swallow unrelated errors
• do not change global SQLite behavior

This matters because a Windows workaround can easily grow into a hidden behavior change. A maintainer reviewing the patch needs to see that the fix is scoped to the observed failure and that other errors still surface normally.

The Review Trail

The PR was linked to the related OpenClaw issue:

• PR: openclaw/openclaw#76024
• Issue: openclaw/openclaw#64187

The bot review asked for maintainer attention and helped frame the risk boundary.

After that, we followed up with local verification and PR notes. The important part was not only saying “it works on my machine”, but writing down the exact checks in a form someone else could inspect later.

That is the difference between a local workaround and an upstreamable fix. A workaround can live in your own notes. An upstream patch needs enough context for maintainers and future contributors.

CI and Merge Evidence

The PR reached a clean enough state for OpenClaw to merge it.

Evidence item	Value
PR	openclaw/openclaw#76024
Related issue	openclaw/openclaw#64187
Status	Merged / Closed
Merged by	steipete
Merged at	2026-05-02 18:07:49 +08:00
Merge commit	f3fd0eedff215967eb75361d241dd5e6cea602e8
Head commit	2b53246ab5cc75a0e46309c52cdc653afcc40d04

The check-run summary we recorded for the head commit was:

Check state	Count
completed	79
success	71
skipped	8
failure	0
cancelled	0

I would not describe that as “every CI job succeeded”, because 8 checks were skipped. The accurate wording is: 79 check runs completed, 71 succeeded, 8 were skipped, and no failure or cancellation was observed.

The final merge screenshot closes the public loop.

Local Verification Commands

The local verification included the focused memory test:

pnpm exec vitest run extensions/memory-core/src/memory/manager.atomic-reindex.test.ts

Result:

1 test file passed
6 tests passed

We also verified under Node 22:

$env:Path = 'D:\nvm4w\nodejs;' + $env:Path
node --version
pnpm exec vitest run extensions/memory-core/src/memory/manager.atomic-reindex.test.ts

Result:

v22.22.2
1 test file passed
6 tests passed

Additional checks included:

pnpm lint:extensions -- extensions/memory-core/src/memory/manager-atomic-reindex.ts extensions/memory-core/src/memory/manager.atomic-reindex.test.ts
pnpm check:changed
git diff --check

These are not decoration. They make the postmortem reproducible.

What This Means for Windows Users

If you run OpenClaw on Windows, the practical meaning is simple:

When memory reindex swaps SQLite index files and Windows briefly reports a file as busy, OpenClaw has a small retry window before giving up.

This does not mean all Windows issues are gone.

It does not cover:

• all SQLite read/write problems;
• all OpenClaw memory search problems;
• gateway startup failures;
• listener or port issues;
• enterprise policy restrictions;
• every file-lock situation on Windows.

It covers one narrow failure path, and that is enough for this PR.

Why We Keep These Records

We keep this type of upstream contribution record because it is useful for both engineering and content.

For engineering, it prevents vague memory. We can point to the PR, issue, CI state, merge commit, screenshots, and local commands.

For writing, it keeps the story honest. The post does not need to claim that one patch solved everything. It only needs to explain what happened, what was fixed, what was not fixed, and how the evidence chain closed.

This PR is now part of our longer-running upstream contribution topic:

• OpenClaw and Hermes upstream contribution records

For future OpenClaw and Windows stability work, this is the record shape we want to keep:

problem screenshot
-> reproduction context
-> local commands
-> patch boundary
-> PR and issue links
-> review thread
-> CI state
-> final merge or close status

That is slower than dropping a quick note in chat. It is also much easier to reuse, review, translate, and trust later.