Summary
Four independent issues found in opencode-mem 2.25.0 on Windows 11 with Node.js v26. Each is described below with environment, steps to reproduce, expected and actual behavior.
Issue 1: AI cleanup aborts mid-run - premature 'close' event (request object)
Component: dist/services/web-server.js
Environment: Windows 11, Node.js v26.5.0, opencode-mem 2.25.0
Steps to reproduce:
- Start opencode-mem on Node.js v26 using the default HTTP server (Web UI / AI cleanup path).
- Trigger an AI cleanup run (e.g. auto-capture cleanup) on a profile.
- Observe the request.
Expected: The request stays alive until the server finishes processing and writes the response.
Actual: The request aborts shortly after the request body is fully consumed (ERR_EMPTY_RESPONSE in the client). On Node v26 with duplex: "half" plus Readable.toWeb(req), the close event on the request fires ~30ms after body consumption - before the real TCP shutdown - which triggers the cleanup/abort handler mid-flight. The log only records an empty response, making the real cause hard to see.
Issue 2: HTTP server timeout (30s) is shorter than inner fetch timeout (60s) - inverted timeout chain
Component: dist/services/web-server.js (server.timeout = 30000)
Environment: Windows 11, Node.js v26.5.0, opencode-mem 2.25.0
Steps to reproduce:
- Use a large profile where AI cleanup takes more than ~30 seconds (e.g. slow remote LLM).
- Trigger cleanup.
- Observe the request.
Expected: The outer HTTP timeout should be the longest layer (a safety net), so it never kills a request that the inner logic is still legitimately processing.
Actual: The HTTP server timeout (30s) is shorter than the fetch-level AbortSignal.timeout(60000) used inside the AI cleanup call. A slow cleanup gets killed by the outer HTTP layer first, producing an empty response, while the inner fetch would still have allowed 30s more.
Observed timeout layers (all different, none derived from a single setting):
| Layer |
Value |
Configurable |
| autoCapture iteration timeout |
30s |
yes (�utoCaptureIterationTimeout) |
| cleanup fetch AbortSignal |
60s |
no (hardcoded) |
| HTTP server.timeout |
30s |
no (hardcoded) |
It would be helpful if at least the HTTP timeout and the cleanup fetch timeout were configurable (or derived from one shared setting).
Issue 3: memoryExtraParams is not forwarded in the AI cleanup external-API request
Component: dist/services/user-profile/ai-cleanup.js
Environment: Windows 11, opencode-mem 2.25.0, SiliconFlow (OpenAI-compatible) with model Qwen/Qwen3-8B
Steps to reproduce:
- Configure "memoryExtraParams": { "enable_thinking": false } in the opencode-mem config to disable reasoning tokens for a thinking-capable model.
- Run AI cleanup against that external API.
- Inspect the request body sent by the cleanup path.
Expected: The configured extra parameters are included in the cleanup request body (consistent with how auto-capture / profile-learning calls are built).
Actual: The cleanup path hand-builds its own fetch and hardcodes the body (model, messages, emperature,
esponse_format), never spreading CONFIG.memoryExtraParams. With a thinking-enabled model this means reasoning stays on by default: a small cleanup prompt generates 3000+ reasoning tokens and blows past the hardcoded 60s AbortSignal.timeout, so cleanup fails/times out.
Issue 4: Web UI search still shows the grand-total count instead of matched count
Component: Web UI (memory list view)
Environment: Windows 11, opencode-mem 2.25.0
Steps to reproduce:
- Open the memory list in the Web UI.
- Run a search that matches only a subset of entries (or none).
- Look at the displayed entry count.
Expected: The count refreshes to the number of matched results for the active search.
Actual: The count still shows the grand total of the whole store, independent of the current search results, so the user cannot tell from the count whether the search found anything.
Summary
Four independent issues found in opencode-mem 2.25.0 on Windows 11 with Node.js v26. Each is described below with environment, steps to reproduce, expected and actual behavior.
Issue 1: AI cleanup aborts mid-run - premature 'close' event (request object)
Component: dist/services/web-server.js
Environment: Windows 11, Node.js v26.5.0, opencode-mem 2.25.0
Steps to reproduce:
Expected: The request stays alive until the server finishes processing and writes the response.
Actual: The request aborts shortly after the request body is fully consumed (ERR_EMPTY_RESPONSE in the client). On Node v26 with duplex: "half" plus Readable.toWeb(req), the close event on the request fires ~30ms after body consumption - before the real TCP shutdown - which triggers the cleanup/abort handler mid-flight. The log only records an empty response, making the real cause hard to see.
Issue 2: HTTP server timeout (30s) is shorter than inner fetch timeout (60s) - inverted timeout chain
Component: dist/services/web-server.js (server.timeout = 30000)
Environment: Windows 11, Node.js v26.5.0, opencode-mem 2.25.0
Steps to reproduce:
Expected: The outer HTTP timeout should be the longest layer (a safety net), so it never kills a request that the inner logic is still legitimately processing.
Actual: The HTTP server timeout (30s) is shorter than the fetch-level AbortSignal.timeout(60000) used inside the AI cleanup call. A slow cleanup gets killed by the outer HTTP layer first, producing an empty response, while the inner fetch would still have allowed 30s more.
Observed timeout layers (all different, none derived from a single setting):
It would be helpful if at least the HTTP timeout and the cleanup fetch timeout were configurable (or derived from one shared setting).
Issue 3: memoryExtraParams is not forwarded in the AI cleanup external-API request
Component: dist/services/user-profile/ai-cleanup.js
Environment: Windows 11, opencode-mem 2.25.0, SiliconFlow (OpenAI-compatible) with model Qwen/Qwen3-8B
Steps to reproduce:
Expected: The configured extra parameters are included in the cleanup request body (consistent with how auto-capture / profile-learning calls are built).
Actual: The cleanup path hand-builds its own fetch and hardcodes the body (model, messages, emperature,
esponse_format), never spreading CONFIG.memoryExtraParams. With a thinking-enabled model this means reasoning stays on by default: a small cleanup prompt generates 3000+ reasoning tokens and blows past the hardcoded 60s AbortSignal.timeout, so cleanup fails/times out.
Issue 4: Web UI search still shows the grand-total count instead of matched count
Component: Web UI (memory list view)
Environment: Windows 11, opencode-mem 2.25.0
Steps to reproduce:
Expected: The count refreshes to the number of matched results for the active search.
Actual: The count still shows the grand total of the whole store, independent of the current search results, so the user cannot tell from the count whether the search found anything.