Skip to content

Fix node capability binding diagnostics#461

Merged
shanselman merged 3 commits into
openclaw:masterfrom
ranjeshj:fix/node-capability-binding-diagnostics
May 19, 2026
Merged

Fix node capability binding diagnostics#461
shanselman merged 3 commits into
openclaw:masterfrom
ranjeshj:fix/node-capability-binding-diagnostics

Conversation

@ranjeshj
Copy link
Copy Markdown
Contributor

Summary

  • Lazily creates NodeService during node ClientCreated so capabilities can bind before connect
  • Logs and records diagnostics when settings, NodeService, or command registration are unavailable instead of silently no-oping
  • Keeps the tray from crashing if capability binding fails

Validation

  • .\build.ps1
  • dotnet test .\tests\OpenClaw.Shared.Tests\OpenClaw.Shared.Tests.csproj --no-restore (1782 passed, 28 skipped)
  • dotnet test .\tests\OpenClaw.Tray.Tests\OpenClaw.Tray.Tests.csproj --no-restore (1112 passed)

ranjeshj and others added 2 commits May 18, 2026 21:01
…e in ClientCreated bridge

Node connections were handshaking with caps=0/cmds=0 because the
NodeConnector.ClientCreated bridge silently no-oped when _nodeService
was null (via the ?. null-conditional on AttachClient). The gateway
recorded the node as having no advertised commands, so the agent could
not invoke anything on it.

_nodeService construction was gated by ShouldInitializeNodeService,
which returns false while _suppressNodeDuringSetup is true. The setup
engine drives node connect through EnsureNodeConnectedAsync which
bypasses that gate, so ClientCreated can fire before _nodeService is
ever built — and after the suppress flag clears nothing reconstructs it.

Fix: lazy-construct NodeService inside the ClientCreated handler so the
capability registrar is guaranteed to exist whenever a node client is
about to connect, independent of OnLaunched ordering or suppress-flag
state. EnsureNodeService is idempotent.

Also rename EnsureNodeServiceForLocalGatewaySetup -> EnsureNodeService:
the original name reflected a single setup-time caller, but it now has
4 call sites and only 1 is setup-related.

Regression introduced 2026-05-12 in 62533e2 when capability registration
moved to the lazy ClientCreated bridge pattern.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Keep the ClientCreated bridge visible when NodeService setup or capability binding cannot populate commands, without crashing the tray app.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@shanselman
Copy link
Copy Markdown
Contributor

Thanks, @ranjeshj. This is the right fix order-wise: node capability binding needs to happen before the node connect handshake serializes caps/commands, and making the ClientCreated bridge construct NodeService lazily closes the setup-time gap.

I reviewed the lifecycle path, ran local validation, and added one small regression test so a throwing ClientCreated bridge records a visible node diagnostic instead of failing silently. The refreshed CI is green.

@shanselman shanselman merged commit b69579f into openclaw:master May 19, 2026
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants