Greptile Summary

This PR fixes a stale closure bug in createGatewayPluginRequestHandler where the registry object captured at handler creation time becomes out of date after a config reload replaces the active registry via setActivePluginRegistry. The fix captures the registry version at handler creation and, on every request, switches to the current live registry if the version has changed — correctly covering the case where channel plugins register webhook routes against the new post-reload registry.

• Fix is correct and well-scoped: The version-based check in plugins-http.ts accurately detects a registry swap and transparently falls through to getActivePluginRegistry(). The ?? registry fallback when the active registry is null is a safe defensive guard.
• Regression test is effective: The new test in plugins-http.test.ts faithfully reproduces the original failure scenario and confirms the fix.
• Minor test hygiene issue: The new test calls setActivePluginRegistry twice (incrementing the global version counter) without restoring state in an afterEach or finally block. While no existing tests are broken today, this leaves the global registry in a modified state and could cause subtle ordering-dependent failures if new tests are added later that assume a clean version counter.

Confidence Score: 4/5

• This PR is safe to merge; the fix is logically correct and well-tested, with only a minor test hygiene concern.
• The implementation is straightforward and the logic is sound. The version-based registry detection correctly handles single and multiple reloads without any race conditions (safe in Node.js's single-threaded model). The one point docked is for the test leaving global state dirty after execution, which is a latent risk for future test additions.
• src/gateway/server/plugins-http.test.ts — the new test should restore global registry state after execution.

This is a comment left during a code review.
Path: src/gateway/server/plugins-http.test.ts
Line: 288-325

Comment:
**Test leaves global registry state dirty**

The test calls `setActivePluginRegistry(registryA)` and `setActivePluginRegistry(registryB)` but never restores the original registry state after the test completes. This also permanently increments the global version counter (each `setActivePluginRegistry` call does `state.version += 1`).

`unregister()` cleans up the late-registered route but leaves `registryB` as the active registry and the version at whatever it was bumped to. While this doesn't break any current tests in the file, it creates a subtle dependency on test execution order. Any future test that creates a handler expecting `creationVersion` to match the `currentVersion` at handler-creation time could silently switch to the live registry if this test has already mutated the global state.

Consider adding an `afterEach` (or a local cleanup via `try/finally`) that restores the original registry reference:

```ts
import { getActivePluginRegistry, setActivePluginRegistry } from "../../plugins/runtime.js";

it("sees routes added to the active registry after a reload replaces it", async () => {
  const originalRegistry = getActivePluginRegistry();
  try {
    // ... test body ...
  } finally {
    if (originalRegistry) setActivePluginRegistry(originalRegistry);
    unregister();
  }
});
```

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: 8c31a08}

We are seeing what looks like the WS/gateway-method analogue of this stale-registry pattern.

In our case, a plugin-backed gateway method (bncr.connect) can be visible in openclaw plugins inspect bncr and method listings, while the live gateway WS still returns unknown method: bncr.connect in the broken state.

Relevant code paths on 2026.3.23-2:

• WS dispatch checks opts.extraHandlers?.[req.method] ?? coreGatewayHandlers[req.method]
• method listing comes from listChannelPlugins().flatMap((plugin) => plugin.gatewayMethods ?? [])
• WS extraHandlers is built from { ...pluginRegistry.gatewayHandlers, ... }
• active plugin registry remains globally replaceable via setActivePluginRegistry(...)

So the shape looks very similar to the HTTP route issue here:

• declaration / inspection path sees one registry view
• live runtime dispatch uses an earlier captured/expanded handler table

I opened a dedicated issue for the WS/gateway-method variant here: #54783

If useful, I can also add a minimal repro focused specifically on plugin gateway methods rather than HTTP routes.