openclaw - 💡(How to fix) Fix Plugin registry cache miss causes 26+ second models.list for custom provider users (v4.29) [1 comments, 2 participants]

Summary

Plugin registry cache never hits for users with custom providers, causing models.list to take 26+ seconds and frequent liveness warnings. Auth stage also takes 9-13 seconds on gateway startup.

Environment

• OpenClaw 2026.4.29 (a448042)
• Custom providers configured in openclaw.json (e.g. xfyun, deepseek, siliconflow)

Symptoms

Root Cause Analysis

Two separate bugs compound to cause the performance regression:

Bug 1: cache: false hardcoded in resolveProviderPluginsForHooks

File: provider-runtime-*.js

resolveProviderPluginsForHooks() hardcodes cache: false when calling resolvePluginProviders():

return resolvePluginProviders({
    ...params,
    mode: "setup",
    cache: false,          // <-- bypasses cache entirely
    ...
});

This causes resolveRuntimePluginRegistry() to skip its cache check (const cacheEnabled = options.cache !== false), triggering a full loadOpenClawPlugins() on every call — filesystem scan, manifest parsing, dependency install.

Fix: Change cache: false → cache: true.

Bug 2: Cache key mismatch in getCompatibleActivePluginRegistry

File: loader-*.js

resolveRuntimePluginRegistry() calls getCompatibleActivePluginRegistry(options) which does strict cache key equality comparison. The cache key is built by buildCacheKey() and includes the full plugins config (allow list, entries with API keys, etc).

When resolveProviderPluginsForHooks is called for a custom provider, the requesting context produces a different plugins description than what the active registry was loaded with:

1. allow list mismatch: The request includes all registered provider IDs (anthropic, byteplus, google, moonshot, tencent, volcengine, xai, etc.), while the active registry only has installed plugin IDs (qqbot, discord, tokenjuice)
2. entries config mismatch: The request has empty plugin entry configs {}, while the active registry has full configs (e.g. {"webSearch":{"apiKey":"tvly-dev-..."}})

Since the cache keys differ, getCompatibleActivePluginRegistry() returns undefined, and resolveRuntimePluginRegistry() falls through to loadOpenClawPlugins() — the slow path — every time.

Why this only affects users with custom providers:

Users without custom providers have consistent allow lists between startup and runtime requests, so cache keys match. Users with custom providers (xfyun, deepseek, etc.) trigger resolveProviderPluginsForHooks with a broader allow list that differs from the active registry's scope, causing permanent cache misses.

The design issue: getCompatibleActivePluginRegistry asks "is this cached result safe to reuse?" but implements it as "does the cache key match exactly?" — these are different questions. A subset compatibility check (requested plugins ⊆ active registry plugins, requested config doesn't conflict) would be more appropriate than strict key equality. The current implementation is overly conservative: even when the active registry contains all needed plugins, it refuses to reuse them because the requesting context has a broader allow list or different entry configs.

Proposed Fixes

Fix 1 (simple): cache: false → cache: true

In resolveProviderPluginsForHooks, change both occurrences of cache: false to cache: true.

Fix 2 (minimal): Active registry fallback

When getCompatibleActivePluginRegistry(options) returns undefined (cache key mismatch), return the already-loaded active registry instead of triggering a full reload:

// Current
function resolveRuntimePluginRegistry(options) {
    if (!options || !hasExplicitCompatibilityInputs(options)) return getCompatibleActivePluginRegistry();
    const compatible = getCompatibleActivePluginRegistry(options);
    if (compatible) return compatible;
    if (isPluginRegistryLoadInFlight(options)) return;
    return loadOpenClawPlugins(options);  // slow path every time
}

// Proposed
function resolveRuntimePluginRegistry(options) {
    if (!options || !hasExplicitCompatibilityInputs(options)) return getCompatibleActivePluginRegistry();
    const compatible = getCompatibleActivePluginRegistry(options);
    if (compatible) return compatible;
    const activeRegistry = getActivePluginRegistry();
    if (activeRegistry) return activeRegistry;  // reuse already-loaded registry
    if (isPluginRegistryLoadInFlight(options)) return;
    return loadOpenClawPlugins(options);
}

Fix 2 (proper): Subset compatibility check in getCompatibleActivePluginRegistry

Instead of strict cache key equality, check whether the requested plugin scope is a subset of the active registry's scope and whether config differences are non-conflicting. This would correctly handle the case where a broader allow list or different entry configs don't affect the validity of the cached result.

Results After Applying Fixes 1 + 2 (minimal)

Reproduction

1. Install OpenClaw 4.29
2. Add custom providers in openclaw.json (e.g. xfyun, deepseek with auth: "api-key" and apiKey fields)
3. Start gateway: openclaw gateway start
4. Run openclaw models list — observe 26+ second delay
5. Check gateway logs for repeated loadOpenClawPlugins calls and liveness warnings