OpenClaw Bug Reports (for GitHub)

Bạn có thể copy/paste nội dung dưới đây để đăng lên trang Issues của kho lưu trữ OpenClaw trên GitHub. Tôi đã chia thành 3 issue riêng biệt vì chúng là 3 lỗi khác nhau.

Issue 1: Disabled plugins (like pdf-tool) still consume initialization time and block the event loop

Description: Even when explicitly disabling a plugin in openclaw.json via "enabled": false, the gateway still appears to initialize or spend significant time on it during the core-plugin-tools phase. This consumes a huge chunk of the 60-second default timeout budget.

Steps to Reproduce:

1. In openclaw.json, set:

   "plugins": {
     "entries": {
       "pdf": { "enabled": false }
     }
   }

2. Start the gateway and inspect the embedded run prep stages in the log.

Expected Behavior: Disabled plugins should be skipped instantly (0ms).

Actual Behavior: The log shows pdf-tool taking over 10 seconds to process despite being disabled:

[trace:embedded-run] core-plugin-tool stages: ... openclaw-tools:pdf-tool:10306ms@12737ms ...

Issue 2: Severe Event Loop Stalls (eventLoopDelayMaxMs > 60,000ms)

Description: The Node.js event loop gets completely blocked for extended periods (sometimes over 60 seconds), triggering severe liveness warnings from the diagnostic subsystem. This usually correlates with network requests (like fetchWithTimeout) or heavy synchronous plugin processing, causing the bot to become completely unresponsive to Telegram webhooks.

Log Evidence:

{"subsystem":"fetch-timeout","message":"fetch timeout reached; aborting operation","elapsedMs":63255,"operation":"fetchWithTimeout"}
{"subsystem":"diagnostic","message":"liveness warning: reasons=event_loop_delay interval=82s eventLoopDelayP99Ms=70.1 eventLoopDelayMaxMs=62511.9 eventLoopUtilization=0.86"}

(Notice the delay max is 62.5 seconds, effectively freezing the Node process).

Suggested Fix: Audit the fetchWithTimeout implementation and any synchronous file/plugin loading logic. Avoid using synchronous blocking calls or while loop sleep hacks that lock the main thread.

Issue 3: Session stickiness traps users in exhausted Fallback loops

Description: When a primary model fails (e.g., model_not_found or timeout) and the fallback model also fails, the session throws a FailoverError: LLM request timed out. However, OpenClaw "remembers" the failed fallback model for that specific sessionId.

If the administrator updates openclaw.json to fix the primary model and restarts the gateway, the user's existing session still tries to use the broken fallback model instead of re-evaluating the new primary model. The user is forced to manually send /new to escape the error loop.

Steps to Reproduce:

1. Configure an invalid primary model and a broken fallback model.
2. Send a message -> triggers chain_exhausted.
3. Admin fixes the primary model in openclaw.json and restarts the gateway.
4. User sends another message (without /new) -> immediately gets FailoverError because the session is sticky to the broken fallback candidate.

Expected Behavior: On a new request, if the previously selected model for the session is failing or if the config has changed, the agent should re-evaluate the routing starting from the primary model, rather than permanently getting stuck in an exhausted fallback state.