fix: memory error

[CarltonXiang]

Pre-submission checklist | 提交前检查

• I have searched existing issues and this hasn't been mentioned before | 我已搜索现有问题，确认此问题尚未被提及
• I have read the project documentation and confirmed this issue doesn't already exist | 我已阅读项目文档并确认此问题尚未存在
• This issue is specific to MemOS and not a general software issue | 该问题是针对 MemOS 的，而不是一般软件问题

Bug Description | 问题描述

i use the plugin in hermes, the error.log of hermes as following:

2026-05-13 16:37:59,610 WARNING [248119d5525e] run_agent: Tool memory_search returned error (30.00s): {"error": "[timeout] memory.search did not respond within 30.0s"}
2026-05-13 16:39:05,618 WARNING [248119d5525e] plugins.memory.memtensor: MemOS: sync_turn turn.end failed — [timeout] turn.end did not respond within 30.0s

How to Reproduce | 如何重现

start
after one or tow hour, ask the agent " What is there in your memory?"

Environment | 环境信息

• pyhton 3.11
• ubuntu 26
• memos v2.0.1

Additional Context | 其他信息

No response

Willingness to Implement | 实现意愿

• I'm willing to implement this myself | 我愿意自己解决
• I would like someone else to implement this | 我希望其他人来解决

[Memtensor-AI]

🤖 AutoDev has picked up this issue and started working on it.

Task ID: 222a060feaf4fae7
Working branch: bugfix/autodev-2028
Target branch: latest dev* branch
Workflow: opsp (analysis → coding → testing → PR)

I will post the PR link here once done. If I need more information, I will ask in the comments.

[Memtensor-AI]

✅ AutoDev task 222a060feaf4fae7 completed.

Summary: Fixes Hermes plugin memory_search / turn.end 30 s timeout regression reported in issue #2028. The Python-side JSON-RPC bridge client silently allowed callers to park for the full per-request timeout whenever the Node bridge subprocess died or hung, and the keepalive path only recovered from transport_closed — a BridgeError("timeout") was logged at DEBUG and dropped, so the dead bridge was reused forever.

Three cooperating fixes were applied to apps/memos-local-plugin/adapters/hermes/memos_provider/: (1) MemosBridgeClient._read_loop now uses try/finally + a new _abort_pending helper so reader-thread exit immediately wakes every parked waiter with transport_closed; (2) MemosBridgeClient.request checks Popen.poll() before writing to stdin, so a dead subprocess fast-fails; (3) MemTensorProvider.handle_tool_call now routes memos_search / memos_get / memos_timeline / memos_skill_list / memos_environment / memos_skill_get through a new _bridge_request_with_retry helper that reconnects and retries once on transport_closed. Keepalive reconnects on timeout / dead subprocess in addition to transport_closed via _should_reconnect_after_keepalive_failure. Write-path (sync_turn) retry semantics are unchanged.

Tests: added 7 BridgeRecoveryTests covering all four layers (reader-exit wake-up, dead-subprocess fast-fail, keepalive-timeout reconnect, keepalive-dead-subprocess reconnect, keepalive-generic-error no reconnect, tool retry success, tool retry failure surfaced). Full runs: python3 -m unittest tests.python.test_bridge_client → 33 tests OK (26 → 33); tests.python.test_hermes_provider_pipeline → 16 tests OK; ruff check + ruff format --check clean.

Note: issue #2028 is a re-report of the closed #1722 regression because the fix landed on bugfix/autodev-1722 against the same base branch (dev-20260624-v2.0.22) and was not merged forward. The same design applies verbatim.

Base branch: main
Branch: bugfix/autodev-2028
Commit: 3359962
PR: #2030
Assigned to: @MatthewZhuang, @CarltonXiang, @syzsunshine219, @World-controller
Reviewers: @MatthewZhuang, @CarltonXiang, @syzsunshine219, @World-controller

[Memtensor-AI]

🤖 AutoDev has picked up this issue and started working on it.

Task ID: 0ceb1ab3d6a84736
Working branch: bugfix/autodev-2028
Target branch: latest dev* branch
Workflow: opsp (analysis → coding → testing → PR)

I will post the PR link here once done. If I need more information, I will ask in the comments.