openclaw - 💡(How to fix) Fix [Bug]: bncr gateway methods can become advertised-but-unknown again after SIGUSR1 in-process hot restart [2 comments, 2 participants]

Summary

On OpenClaw v2026.4.26, bncr is healthy after a full cold restart, but can still regress on SIGUSR1 / OPENCLAW_NO_RESPAWN in-process hot restart: plugin logs show bncr.connect registered, yet live gateway WS requests later return unknown method: bncr.connect.

This looks like an uncovered variant or regression relative to #54783 rather than a totally unrelated bug.

Repro shape

Environment:

• OpenClaw 2026.4.26
• gateway restart path in this environment is SIGUSR1
• log explicitly shows restart mode: in-process restart (OPENCLAW_NO_RESPAWN)
• bncr plugin source loaded from workspace plugin dir

Observed sequence:

1. Full restart baseline is healthy.
2. Trigger hot restart (SIGUSR1 / in-process restart).
3. Plugin logs show successful gateway method registration, e.g. debug register method ok bncr.connect.
4. Loader/registry diagnostics then emit gateway method already registered: bncr.connect (and peers).
5. New WS requests later fail with unknown method: bncr.connect.

So this is not just “registration never happened”. The advertised/observed registration state and live WS dispatch table diverge after in-process restart.

Key evidence

Representative timeline from logs:

• signal SIGUSR1 received
• received SIGUSR1; restarting
• restart mode: in-process restart (OPENCLAW_NO_RESPAWN)
• [bncr] debug register method ok bncr.connect
• gateway method already registered: bncr.connect
• http server listening
• later WS dispatch: unknown method: bncr.connect

Also confirmed separately:

• full restart restores functionality
• issue reproduces on fresh new connections, not just a single stale connection
• plugin method listing / plugin-side logs can indicate the method exists while WS dispatch still misses it

Source-level findings from local inspection

From current dist files on the host:

1. handleGatewayRequest(...) dispatches plugin methods through opts.extraHandlers?.[req.method] ?? coreGatewayHandlers[req.method].
2. attachGatewayWsHandlers(...) receives an object-spread snapshot of plugin handlers:
   • extraHandlers: { ...pluginRegistry.gatewayHandlers, ...extraHandlers }
3. loadOpenClawPlugins(...) uses process-level plugin loader cache (getCachedPluginRegistry(...) / setCachedPluginRegistry(...)) and can directly reuse cached registry objects when the cache key matches.
4. The in-process restart shutdown path closes ws/http transport, but we did not find production-path evidence that it also clears plugin loader cache or fully resets active plugin runtime registry state.
5. releasePinnedPluginChannelRegistry() is not equivalent to clearing active registry/cache.

Current best hypothesis:

• SIGUSR1 in-process restart preserves plugin loader cache and/or active runtime plugin registry state
• loadOpenClawPlugins() reuses an old registry object
• attachGatewayWsHandlers() then builds the new WS dispatch table from stale pluginRegistry.gatewayHandlers
• result: plugin logs can show registration success in some registry path, while live WS dispatch still lands on unknown method: bncr.connect

Why this seems related to #54783

#54783 described the same outward symptom family: plugin gateway methods visible in inspect/listings, but live WS dispatch returning unknown method.

What seems new here is the stronger hot-restart-specific evidence chain around:

• SIGUSR1 / OPENCLAW_NO_RESPAWN
• process-local plugin loader cache reuse
• active registry lifetime crossing in-process restart boundaries
• WS attach using a snapshot of pluginRegistry.gatewayHandlers

So the most likely framing is: this is either an uncovered hot-restart variant of #54783 or a regression after the earlier fix path.

Additional bncr-specific note

During the same investigation we also narrowed plugin-side risk factors:

• bncr uses a process-global singleton bridge (globalThis.__bncrBridge)
• plugin registration currently appears too permissive around discovery/full boundaries

Those may amplify the symptom, but the host-side cache/registry lifetime mismatch still looks like the main shared failure plane.

Suggested validation / fix directions

The most valuable next experiment would be to force a fresh plugin registry on hot restart and see whether the issue disappears:

• clear plugin loader cache on SIGUSR1 hot restart, or
• fully reset active plugin runtime registry state before deferred plugin reload, or
• force gateway plugin reload on hot restart to bypass cached registry reuse

If doing a code fix, the likely hotspots are:

• plugin loader cache lifecycle around in-process restart
• active plugin runtime registry reset semantics
• hot-restart path before reloadDeferredGatewayPlugins(...)
• ensuring attachGatewayWsHandlers(...) always sees a fresh handler map after hot restart

Local references

Relevant local investigation notes:

• memory/docs/bncr-hot-restart-manifest-register-drift-2026-04-28.md
• memory/docs/bncr-openclaw-hot-restart-gateway-method-loss-2026-04-29.md

If helpful, I can also provide the exact local log snippets/timestamps and dist file paths used for the above source inspection.