Bug: process alive but HTTP endpoints hang, causing AbortError in memory_store/auto-capture

[JerryLeibniz]

Summary

When using memory-openviking in local mode, memory_store / auto-capture can fail with:

• AbortError: This operation was aborted
• or extract returned 0 memories

In our case, the OpenViking process is still alive and TCP port 1933 is connectable, but HTTP endpoints such as /health and /api/v1/system/status stop responding. The plugin then aborts requests after timeoutMs.

This looks like a service-hang / internal queue blockage case rather than a simple startup failure.

Environment

• OpenClaw: 2026.3.7
• Host: macOS arm64
• memory plugin: memory-openviking
• OpenViking mode: local
• OpenViking port: 1933

memory-openviking config

{
  "mode": "local",
  "configPath": "~/.openviking/ov.conf",
  "targetUri": "viking://user/memories",
  "autoCapture": true,
  "autoRecall": true,
  "apiKey": "openviking-local",
  "timeoutMs": 120000
}

OpenViking config

{
  "server": {
    "host": "127.0.0.1",
    "port": 1933
  },
  "embedding": {
    "max_concurrent": 10
  },
  "vlm": {
    "provider": "openai",
    "api_base": "http://127.0.0.1:8317/v1",
    "model": "gpt-5",
    "max_concurrent": 10,
    "max_retries": 2
  }
}

Symptoms

Observed logs include:

• memory-openviking: auto-capture failed: AbortError: This operation was aborted
• memory-openviking: memory_store failed: AbortError: This operation was aborted
• memory-openviking: auto-capture completed but extract returned 0 memories
• memory-openviking: memory_store completed but extract returned 0 memories
• upstream timeouts / rate-limit related failures also appeared around the same period

Key observation

The OpenViking process is still running, and TCP connect to 127.0.0.1:1933 succeeds immediately.

However, HTTP requests time out with no bytes returned:

• /health
• /api/v1/system/status
• /api/v1/observer/vlm
• /api/v1/observer/vikingdb

So this seems to be a case where:

1. process is alive
2. port is open
3. but the HTTP service is internally blocked / hung

Reproduction pattern

This is easier to trigger under heavier memory traffic, for example when several of these happen close together:

• auto-capture
• memory_store
• batch import / repeated extract
• VLM / embedding concurrency set relatively high

Expected behavior

If OpenViking becomes internally blocked:

• plugin should surface a clearer cause than generic AbortError
• local-mode health checks should detect “process alive but HTTP hung”
• ideally there should be recovery / restart / circuit-breaker behavior

Actual behavior

• process stays alive
• plugin requests abort on timeout
• memory ingestion becomes unreliable
• logs make it look like a request failure, while the deeper problem is likely service hang

Possible areas to inspect

• OpenViking internal request queue / worker starvation
• VLM / embedding concurrency interaction
• local-mode process supervision and hung-service detection
• more explicit distinction between:
  • startup failure
  • upstream provider failure
  • HTTP hang while process remains alive

Additional note

This is not caused by invalid content being stored. The same failure affects:

• memory_store
• auto-capture
• health/status observer endpoints

[qin-ctx]

Root Cause Analysis

The server uses a single uvicorn worker (single event loop) by default (bootstrap.py:150-166). All route handlers are async def and share this one event loop.

The critical blocker is in the old Session.commit() code path (session.py:262), which calls run_async() from within the async context. run_async() (async_utils.py:75-93) spawns a thread and blocks on t.join() — this freezes the event loop entirely. Once blocked, no other request can be served, including /health.

Why the process appears alive but HTTP is dead:

• Process is running, TCP port accepts connections
• But the single event loop is frozen by t.join(), so no HTTP response can be produced

Fix direction:

• Eliminate run_async() blocking calls from async context, use proper await instead
• Increase uvicorn workers to limit blast radius
• Add request-level timeout middleware as a safety net

[werfei]

我遇到了相同的问题，请问这个如何解决，本地模式会直接导致openclaw的调用超时，remote模型又有这个问题