Skip to content

fix(memory): support Windows memory file locking - #8563

Closed
XiaoXiao0221 wants to merge 1 commit into
NousResearch:mainfrom
XiaoXiao0221:fix/memory-tool-windows-lock
Closed

fix(memory): support Windows memory file locking#8563
XiaoXiao0221 wants to merge 1 commit into
NousResearch:mainfrom
XiaoXiao0221:fix/memory-tool-windows-lock

Conversation

@XiaoXiao0221

@XiaoXiao0221 XiaoXiao0221 commented Apr 12, 2026

Copy link
Copy Markdown
Contributor

What does this PR do?

This fixes a Windows compatibility bug in tools/memory_tool.py.

On main, the memory tool still imports fcntl unconditionally, which prevents the tool from loading on Windows. This revision keeps Unix behavior on fcntl, adds a Windows lock path via msvcrt, and preserves retry/timeout handling so concurrent writers do not fail immediately.

The Windows lock path also passes msvcrt.locking() an integer file descriptor from the lock file handle. Without that, memory mutations can fail at runtime with TypeError: '_io.TextIOWrapper' object cannot be interpreted as an integer.

Related Issue

No linked issue.

Type of Change

  • 🐛 Bug fix (non-breaking change that fixes an issue)
  • ✨ New feature (non-breaking change that adds functionality)
  • 🔒 Security fix
  • 📝 Documentation update
  • ✅ Tests (adding or improving test coverage)
  • ♻️ Refactor (no behavior change)
  • 🎯 New skill (bundled or hub)

Changes Made

  • add backend detection for fcntl and msvcrt in tools/memory_tool.py
  • keep Unix locking on fcntl.flock()
  • keep Windows locking on msvcrt.locking() with retry + timeout behavior
  • pass an integer file descriptor to msvcrt.locking() instead of a file object
  • add regression tests for Windows high-level add flow, integer file descriptors, retry behavior, timeout behavior, and Unix lock preservation

How to Test

  1. Run pytest tests/tools/test_memory_tool.py -q
  2. On Windows, start hermes and verify it no longer logs Could not import tool module tools.memory_tool: No module named 'fcntl'
  3. Exercise memory add -> reload -> remove and confirm writes succeed across sessions

Checklist

Code

  • I've read the Contributing Guide
  • My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
  • I searched for existing PRs to make sure this isn't a duplicate
  • My PR contains only changes related to this fix/feature (no unrelated commits)
  • I've run pytest tests/ -q and all tests pass
  • I've added tests for my changes (required for bug fixes, strongly encouraged for features)
  • I've tested on my platform: Windows 11 (PowerShell 7)

Documentation & Housekeeping

  • I've updated relevant documentation (README, docs/, docstrings) — or N/A
  • I've updated cli-config.yaml.example if I added/changed config keys — or N/A
  • I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
  • I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
  • I've updated tool descriptions/schemas if I changed tool behavior — or N/A

Screenshots / Logs

  • pytest tests/tools/test_memory_tool.py -q -> 37 passed
  • Manual smoke test on Windows add/reload/remove via MemoryStore -> all succeeded
  • Startup validation on Windows PowerShell 7: hermes no longer emits Could not import tool module tools.memory_tool: No module named 'fcntl'
  • pytest tests/ -x -vv on Windows still fails during collection in tests/hermes_cli/test_gateway_service.py because it imports the Unix-only pwd module (ModuleNotFoundError: No module named 'pwd')
  • The current full-suite failure therefore appears to be an existing Windows test-suite issue unrelated to this memory tool change

@XiaoXiao0221

Copy link
Copy Markdown
Contributor Author

A few reviewer-facing notes for context:

  • This PR is intentionally scoped to tools/memory_tool.py only. I split the gateway-side Windows fixes into a separate PR so this one stays focused on the memory tool path.
  • The Unix behavior is preserved: non-Windows platforms still use fcntl.flock() exactly as before. The new branch only affects sys.platform == "win32".
  • The Windows runtime bug here was two-part:
    1. unconditional fcntl import blocked tool loading on Windows
    2. msvcrt.locking() requires an integer file descriptor, so passing the file object caused runtime mutation failures
  • Validation performed on Windows 11 / PowerShell 7:
    • pytest tests/tools/test_memory_tool.py -q -> 34 passed
    • manual MemoryStore add / replace / remove smoke test -> all succeeded
  • I did not mark the full test suite as passing because pytest tests/ -x -vv currently stops earlier in tests/hermes_cli/test_gateway_service.py on Windows due to a separate pwd import issue, which appears unrelated to this memory-tool change.

@XiaoXiao0221
XiaoXiao0221 force-pushed the fix/memory-tool-windows-lock branch from e3250b0 to cdb0b6a Compare April 13, 2026 17:13
@XiaoXiao0221 XiaoXiao0221 changed the title fix(tools): support Windows memory file locking fix(memory): support Windows memory file locking Apr 13, 2026
@XiaoXiao0221
XiaoXiao0221 force-pushed the fix/memory-tool-windows-lock branch from cdb0b6a to 0bc4b87 Compare April 15, 2026 15:06
@teknium1

Copy link
Copy Markdown
Contributor

Thanks for the contribution, @XiaoXiao0221!

Closing this as a duplicate of #6479 (by @iacker), which targets the same fix/feature. We're consolidating on that PR for review.

If you want to help push it over the line, please jump in there — or if you think your approach is better for a specific reason that isn't covered in the other PR, let us know and we can reopen.

@teknium1 teknium1 closed this Apr 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants