Problem
The gateway log shows repeated warns:
unknown typed hook 'shutdown' ignored
unknown typed hook 'close' ignored
unknown typed hook 'restart' ignored
unknown typed hook 'reload' ignored
These come from packages/adapter-openclaw/openclaw-entry.mjs:102-104:
if (typeof api.on === 'function') {
const reset = () => { /* singleton reset on teardown */ };
for (const event of ['shutdown', 'close', 'restart', 'reload']) {
api.on(event, reset);
}
}
The intent was to wire singleton teardown to whichever lifecycle event the gateway emits. The gateway interprets the names as typed hooks (not lifecycle events), none are in its typed-hook registry, and emits one warn per unknown name on every plugin (re-)register. With multi-phase init re-binding the plugin every turn, these warns multiply.
Impact
Pure log noise — the singleton-reset path is non-critical (the singleton would re-initialize on next register anyway). No functional regression.
Suggested fix
Two options, either works:
- Detect first. Check which event name the current gateway version actually advertises (likely one of
unload / dispose / disable / a versioned name) and register only that one.
- Drop the listeners. The singleton's
instance.register(api) re-bind in the multi-phase-init branch already handles the in-process restart case correctly. The teardown path on full process exit is the OS's job. Removing lines 95-105 entirely is the simplest fix and removes a stale heuristic.
Option 2 is preferred unless we discover a gateway-shutdown scenario that the singleton actually needs to react to.
Context
Surfaced during PR #264 live-test triage. Filed as post-merge follow-up.
Problem
The gateway log shows repeated warns:
These come from
packages/adapter-openclaw/openclaw-entry.mjs:102-104:The intent was to wire singleton teardown to whichever lifecycle event the gateway emits. The gateway interprets the names as typed hooks (not lifecycle events), none are in its typed-hook registry, and emits one warn per unknown name on every plugin (re-)register. With multi-phase init re-binding the plugin every turn, these warns multiply.
Impact
Pure log noise — the singleton-reset path is non-critical (the singleton would re-initialize on next register anyway). No functional regression.
Suggested fix
Two options, either works:
unload/dispose/disable/ a versioned name) and register only that one.instance.register(api)re-bind in the multi-phase-init branch already handles the in-process restart case correctly. The teardown path on full process exit is the OS's job. Removing lines 95-105 entirely is the simplest fix and removes a stale heuristic.Option 2 is preferred unless we discover a gateway-shutdown scenario that the singleton actually needs to react to.
Context
Surfaced during PR #264 live-test triage. Filed as post-merge follow-up.