fix(gateway): keep N-1 nodes manageable during upgrades#101109
Conversation
openclaw-barnacle
Bot
added
docs
2db2e19 to
e43dc98
Compare
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2db2e19ede
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ...registry.nodeHostCommands.map((entry) => entry.pluginId), | ||
| ...registry.nodeInvokePolicies.map((entry) => entry.pluginId), | ||
| ]); | ||
| const pluginCaps = new Set([...params.pluginSurfaces, ...pluginIds]); |
There was a problem hiding this comment.
When a plugin node-host command advertises a cap that differs from the plugin id or hosted surface, this legacy filter removes the plugin commands but leaves the cap visible. For example, file-transfer registers file.* commands with cap file, so an N-1 node still advertises file in node/environment capability lists even though the corresponding commands were withheld for the session; cap-based callers and users then see an unusable plugin surface until invocation fails. Include nodeHostCommands' command.cap values in this set before filtering caps.
Useful? React with 👍 / 👎.
e43dc98 to
a407227
Compare
|
Land-ready on exact head What was verified:
Known proof gaps: none. |
|
Merged via squash.
|
1 participant
Closes #83736
AI-assisted: yes
What Problem This Solves
Fixes an issue where staged Gateway upgrades could strand subordinate nodes when the node still spoke the immediately previous Gateway protocol. The Gateway rejected those nodes before pairing, status, update, restart, or other approved maintenance paths became available.
Why This Change Was Made
The Gateway now accepts an exact N-1 window for authenticated
role: "node"/client.mode: "node"clients and lightweight probes, while operator and UI clients remain pinned to the current protocol. Device authentication, pairing, scopes, node command policy, and exec approvals remain mandatory. Because protocol v3 predates plugin-hosted surfaces, legacy sessions hide plugin-owned capabilities and commands until upgrade; a session ceiling keeps that restriction intact across later pairing approvals without changing the durable pairing declaration.The N-1 constants and guard force a deliberate compatibility decision at the next protocol bump. Public Gateway and node docs now define the supported window and safe upgrade order.
User Impact
Operators can upgrade a Gateway first and then upgrade protocol N-1 nodes without losing the Gateway-managed maintenance path. Nodes older than N-1 remain rejected, and N-1 nodes expose only the stable core surface until they upgrade.
Evidence
tbx_01kww83sbts5xrapfbaebncfsj; warmup run https://github.com/openclaw/openclaw/actions/runs/28811054190pnpm build: passed on the post-rebase exact treepnpm protocol:check: generated protocol schema and Swift models remained cleanpnpm check:changed: core/test typechecks, full core lint, import-cycle, database/storage, webhook, and pairing guards passed