openclaw - 💡(How to fix) Fix [Bug] Session file lock timeout causes false model fallback (MiniMax ? DeepSeek)

Description

When a main session is in the middle of processing an embedded_run, subsequent runs (e.g., active-memory plugin, channel dispatches to the same session) fail to acquire the session JSONL write lock. This causes Gateway to record a false model failure - even though the primary model API call never actually started.

Evidence

model_fallback_decision: requestedProvider: "minimax-portal" requestedModel: "MiniMax-M2.7" fallbackStepFromFailureReason: "unknown" fallbackStepFromFailureDetail: "session file locked (timeout 60000ms): pid=18948 C:\.openclaw\agents\main\sessions\uuid....lock"

Impact

• Primary model unfairly swapped for fallback due to Gateway-internal locking, not model unavailability
• User sees "model fallback" in logs and thinks MiniMax is unreliable
• False negatives make it hard to diagnose real model issues
• Cascading effect: when EventLoop is also blocked by weixin plugin, the problem compounds

Suggested Fix

1. Separate the session lock timeout from the model failure classification - a failed lock should NOT count as a model failure attempt
2. Implement non-blocking session writes (queue writes or async file handles instead of file lock)
3. Make session lock timeout configurable

Environment

• OS: Windows
• Model: MiniMax-M2.7 (primary), deepseek-v4-flash (fallback)