mirror of
https://github.com/openclaw/openclaw.git
synced 2026-08-25 03:45:46 -06:00
Florian
e1b1d4ba7c
* fix(config): stop plugin schemas rejecting the channel key core writes A published channel plugin declares a closed config schema listing only the keys it knew about when that version shipped. Core's doctor migration writes heartbeatVisibility into channels.<id> and its accounts for every channel, so a plugin predating that key turns config core itself produced into a gateway that refuses to start with 78/CONFIG — and doctor --fix reports it without repairing it, leaving no in-product recovery. This took the live gateway down after the last deploy: @openclaw/signal 2026.7.2-beta.3 ships a 44-property closed schema with no heartbeatVisibility, while core reads all three precedence layers (src/infra/heartbeat-visibility.ts) and documents them (docs/gateway/heartbeat.md). Channel schemas built from core's shape may omit common fields on purpose — buildCommonChannelAccountShape takes an `omit` list — so widening every common key would silently accept config that can never take effect. The fix stays on the keys core writes: core wrote it, so core accepts it. Everything else is untouched, including unknown-key rejection, which is covered by a test and verified end to end. Applied once when the channel schema map is built, so the AJV cache key still maps to exactly one schema per channel, and unchanged schemas are returned by identity. Verified against the real failure: with the live plugin set loaded, the config that crashed the gateway now validates at both channel and per-account level, while an unknown key on the same channel is still rejected. * fix(config): normalize external channel schemas at metadata owner * fix(config): normalize core-owned channel visibility schemas * style(config): format channel metadata regression coverage * refactor(config): simplify channel schema normalization coverage --------- Co-authored-by: Peter Steinberger <steipete@gmail.com>