PR #61785: fix(plugins): reuse gateway-bindable active registry for default runtime requests

• Repository: openclaw/openclaw
• Author: zfaustk
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/61785

Description (problem / solution / changelog)

Summary

• Problem: plugin loads started from a gateway-bindable runtime were not reused by later default runtime requests, so OpenClaw could trigger redundant plugin register() passes.
• Why it matters: this matches openclaw/openclaw#61756, where repeated cache misses caused many extra plugin reloads during normal gateway message handling.
• What changed: getCompatibleActivePluginRegistry() now treats an active gateway-bindable registry as compatible with a default runtime request when the rest of the cache context still matches, and src/plugins/loader.runtime-registry.test.ts adds regression coverage for that path.
• What did NOT change (scope boundary): this does not change cache-key construction, runtime mode semantics outside this compatibility check, or any plugin activation behavior unrelated to default-versus-gateway-bindable registry reuse.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #61756
• Related #61756
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: the active registry cache key encoded runtimeSubagentMode, so a registry created with allowGatewaySubagentBinding=true could not be reused by later default-runtime lookups even when all other compatibility inputs matched.
• Missing detection / guardrail: there was no regression test for the gateway-bindable active registry default runtime lookup path.
• Contributing context (if known): message-processing call sites can mix gateway-bindable startup loads with later default runtime requests.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/plugins/loader.runtime-registry.test.ts
• Scenario the test should lock in: an active registry created with allowGatewaySubagentBinding: true should still be reused when a later request only asks for the default runtime and the remaining cache context matches.
• Why this is the smallest reliable guardrail: the bug is in loader compatibility resolution, so this test hits the exact decision point without needing a full gateway repro.
• Existing test that already covers this (if any): none.
• If no new test is added, why not: N/A.

User-visible / Behavior Changes

• Plugin registries created during gateway-bindable startup should now be reused by later default runtime requests instead of forcing redundant plugin reloads.

Diagram (if applicable)

Before:
[gateway-bindable startup load] -> [active registry cached under gateway-bindable mode]
[default runtime request] -> [cache miss] -> [reload + register() again]

After:
[gateway-bindable startup load] -> [active registry cached under gateway-bindable mode]
[default runtime request] -> [compatibility fallback hit] -> [reuse active registry]

Security Impact (required)

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (No)
• New/changed network calls? (No)
• Command/tool execution surface changed? (No)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: Ubuntu 24.04 for the reported issue; local verification ran in the ROOM shell environment.
• Runtime/container: Node 20.20.2
• Model/provider: N/A
• Integration/channel (if any): plugin loader / gateway runtime path
• Relevant config (redacted): plugin allowlist with allowGatewaySubagentBinding: true

Steps

1. Create an active plugin registry using a load context with allowGatewaySubagentBinding: true.
2. Resolve the compatible active registry with the same plugin/workspace context but without explicit runtime options.
3. Verify that the active registry is reused instead of returning undefined and forcing a reload.

Expected

• The default runtime request reuses the existing active registry.

Actual

• Before this patch, the default runtime request missed the active registry because the cache key only matched the gateway-bindable variant.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios: node scripts/run-vitest.mjs run --config vitest.plugins.config.ts src/plugins/loader.runtime-registry.test.ts and node scripts/run-vitest.mjs run --config vitest.plugins.config.ts src/plugins/tools.optional.test.ts -t gateway-bindable both exited 0; git diff --check also passed locally.
• Edge cases checked: the existing cache-key mismatch cases for different workspace and onlyPluginIds inputs still remain covered in the same test file.
• What you did not verify: a full gateway/channel repro with live Telegram traffic, and full-repo green beyond the targeted checks above.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: treating gateway-bindable as a superset could accidentally reuse an incompatible registry if another compatibility input differs.
  • Mitigation: the fallback only returns the active registry when recomputing the same cache context with allowGatewaySubagentBinding: true matches the active cache key exactly.

Changed files

• src/plugins/loader.runtime-registry.test.ts (modified, +22/-3)
• src/plugins/loader.ts (modified, +24/-3)

PR #61854: Fix: exclude runtimeSubagentMode from plugin loader cache key (Resolves #61756)

• Repository: openclaw/openclaw
• Author: Mlightsnow
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/61854

Description (problem / solution / changelog)

Fixes #61756.

The plugin loader cache key included runtimeSubagentMode, which is derived from allowGatewaySubagentBinding. Different call sites in the message processing pipeline pass different values for this flag (some with allowGatewaySubagentBinding: true, some without), producing distinct cache keys and triggering redundant register() calls — 40+ in 24 seconds after startup as reported.

runtimeSubagentMode does not affect which plugins are loaded or how they are configured. It is only metadata stored alongside the active registry state (via setActivePluginRegistry). Removing it from the cache key lets all call sites share the same cached registry regardless of their binding mode, while the active state's runtimeSubagentMode is still correctly updated on each activation.

Changes:

• Remove runtimeSubagentMode from buildCacheKey() parameters and cache key string in src/plugins/loader.ts
• Update test: replace the old "does not reuse cached registries across gateway subagent binding modes" test case with a cache-miss test for pluginSdkResolution (which is still a valid cache key dimension)
• Add new test verifying that registries ARE reused across gateway subagent binding modes

Testing:

• pnpm check passes
• pnpm build passes (no [INEFFECTIVE_DYNAMIC_IMPORT] warnings)
• All 138 loader tests pass
• Plugin tools optional tests pass (15/15)

AI-assisted (Claude). Fully tested. I understand the changes.

Changed files

• src/plugins/loader.runtime-registry.test.ts (modified, +34/-1)
• src/plugins/loader.test.ts (modified, +37/-4)
• src/plugins/loader.ts (modified, +26/-6)