Summary

After upgrading OpenClaw from a working older build to 2026.3.28, our local setup started behaving incorrectly. Rolling back to 2026.3.24 immediately restores normal behavior.

At the moment this looks like an OpenClaw regression rather than a problem in our local reranker server or in memory-lancedb-pro alone.

What changed after upgrading to 2026.3.28

1) memory-lancedb-pro started resolving sessionStrategy as none

After the upgrade, logs showed:

session-strategy: using none (plugin memory-reflection hooks disabled)

This disabled memory-reflection hooks unexpectedly.

As a workaround, explicitly setting:

"plugins": {
  "entries": {
    "memory-lancedb-pro": {
      "config": {
        "sessionStrategy": "memoryReflection"
      }
    }
  }
}

and restarting restored:

memory-reflection: integrated hooks registered (command:new, command:reset, after_tool_call, before_prompt_build, session_end)

So something in 2026.3.28 appears to have changed how runtime/plugin config is resolved.

2) Discord interaction handling became slower

Logs also showed:

[EventQueue] Slow listener detected: InteractionEventListener took 4254ms for event INTERACTION_CREATE

and later:

[EventQueue] Slow listener detected: InteractionEventListener took 2240ms for event INTERACTION_CREATE

3) Embedded websocket streaming started failing

Repeated logs:

[ws-stream] WebSocket connect failed ... Unexpected server response: 500
falling back to HTTP

This started appearing around the same time and may be part of the same regression.

What is NOT the problem

Reranker server is healthy

Local reranker endpoint is up and responds correctly:

• endpoint: http://127.0.0.1:18799/v1/rerank
• server process is running normally
• manual POST test returns 200 OK

So the reranker itself is not the root cause.

Rolling back OpenClaw fixes it

Most importantly:

• OpenClaw 2026.3.28 → broken / degraded behavior
• OpenClaw 2026.3.24 → works normally again

That strongly suggests an OpenClaw-side regression introduced after 2026.3.24.

Environment

• OS: Windows 10.0.26200 x64
• Node: 24.13.0
• OpenClaw problematic version: 2026.3.28
• OpenClaw known-good rollback: 2026.3.24
• Plugin: [email protected]

Relevant config excerpts

Agent defaults

"agents": {
  "defaults": {
    "memorySearch": {
      "enabled": false
    }
  }
}

memory-lancedb-pro

"plugins": {
  "entries": {
    "memory-lancedb-pro": {
      "enabled": true,
      "config": {
        "autoCapture": true,
        "autoRecall": true,
        "embedding": {
          "baseURL": "http://localhost:11434/v1",
          "model": "jina-v5-retrieval-test",
          "dimensions": 1024
        },
        "retrieval": {
          "mode": "hybrid",
          "rerank": "cross-encoder",
          "rerankProvider": "siliconflow",
          "rerankModel": "BAAI/bge-reranker-base",
          "rerankEndpoint": "http://127.0.0.1:18799/v1/rerank",
          "rerankApiKey": "local"
        },
        "autoRecallTimeoutMs": 120000
      }
    }
  }
}

Why I think this should be investigated in OpenClaw

Because the problem disappears completely on rollback to 2026.3.24, I suspect one or more regressions in 2026.3.28 related to:

1. plugin config resolution / default propagation into plugin runtime
2. session strategy behavior affecting plugin hook registration
3. embedded websocket streaming (ws-stream) behavior
4. Discord interaction handling latency in the event queue

Request

Could you help identify which change after 2026.3.24 caused:

• memory-lancedb-pro to behave as if sessionStrategy=none
• websocket streaming to start failing with HTTP 500 fallback
• Discord interaction listener latency to increase noticeably

If needed, I can provide more logs and a more minimal reproduction.