Skip to content

fix(gateway): include device identity in probe clients#48617

Closed
Oclw-bot wants to merge 1 commit intoopenclaw:mainfrom
Oclw-bot:fix/gateway-status-loopback-device-identity
Closed

fix(gateway): include device identity in probe clients#48617
Oclw-bot wants to merge 1 commit intoopenclaw:mainfrom
Oclw-bot:fix/gateway-status-loopback-device-identity

Conversation

@Oclw-bot
Copy link
Copy Markdown

@Oclw-bot Oclw-bot commented Mar 17, 2026

Summary

  • Problem: openclaw status / gateway probe paths could report unreachable (missing scope: operator.read) against a healthy local loopback gateway.
  • Why it matters: the gateway was reachable and authenticated, but probe clients dropped device identity on loopback, so the probe lost the paired-device scope path and misreported health.
  • What changed: src/gateway/probe.ts now passes loadOrCreateDeviceIdentity() into probe clients, matching normal gateway call behavior.
  • What did NOT change (scope boundary): no gateway auth mode, pairing policy, or scope semantics changed; this only fixes how probe clients identify themselves.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #
  • Related #

User-visible / Behavior Changes

  • openclaw status / gateway probe output no longer falsely reports a healthy loopback gateway as unreachable with missing scope: operator.read when device pairing/scopes are otherwise valid.

Security Impact (required)

  • New permissions/capabilities? (No)
  • Secrets/tokens handling changed? (No)
  • New/changed network calls? (No)
  • Command/tool execution surface changed? (No)
  • Data access scope changed? (No)
  • If any Yes, explain risk + mitigation:

Repro + Verification

Environment

  • OS: Debian 13 / Linux 6.12.73+deb13-arm64
  • Runtime/container: Node v22.22.0
  • Model/provider: n/a
  • Integration/channel (if any): local gateway / CLI status path
  • Relevant config (redacted): gateway.mode=local, gateway.bind=loopback, token auth enabled, paired operator device present

Steps

  1. Run a local loopback gateway with token auth and a paired operator device.
  2. Run openclaw status (or a code path that uses probeGateway()).
  3. Observe the probe result.

Expected

  • The probe connects with the same device identity semantics as normal CLI gateway calls and reports the loopback gateway as reachable.

Actual

  • The probe connected without device identity on loopback and could degrade to missing scope: operator.read, even though direct gateway calls were healthy.

Evidence

Attach at least one:

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

  • Verified scenarios:
    • Reproduced the false-negative openclaw status behavior locally against a healthy loopback gateway.
    • Confirmed direct gateway status calls were healthy while openclaw status still showed missing scope: operator.read.
    • Applied the equivalent runtime fix locally and confirmed openclaw status switched to reachable.
    • Added a regression test asserting probe clients now include deviceIdentity.
    • Ran corepack pnpm vitest run src/gateway/probe.test.ts successfully.
  • Edge cases checked:
    • Loopback probe still requests only operator.read scope.
    • Change is limited to probe client identity construction.
  • What you did not verify:
    • Full repository test suite.
    • Remote/non-loopback gateway probe behavior in a second environment.

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

  • Backward compatible? (Yes)
  • Config/env changes? (No)
  • Migration needed? (No)
  • If yes, exact upgrade steps:

Failure Recovery (if this breaks)

  • How to disable/revert this change quickly: revert this PR / commit.
  • Files/config to restore: src/gateway/probe.ts, src/gateway/probe.test.ts
  • Known bad symptoms reviewers should watch for: unexpected device-auth regressions in probe-only code paths.

Risks and Mitigations

  • Risk: probe clients now present device identity on loopback where they previously did not.
    • Mitigation: this aligns probe behavior with existing normal CLI gateway call behavior rather than introducing a new auth mechanism.

@openclaw-barnacle openclaw-barnacle bot added gateway Gateway runtime size: XS labels Mar 17, 2026
@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps bot commented Mar 17, 2026

Greptile Summary

This PR fixes a false-negative in openclaw status / gateway probe paths by passing loadOrCreateDeviceIdentity() into the probe's GatewayClient, making probe clients present the same device identity as normal CLI gateway calls. Previously, probe clients on loopback omitted device identity, which could cause the paired-device scope path to be lost and produce a spurious missing scope: operator.read error against a healthy gateway.

Key observations:

  • The fix is minimal, targeted, and correct — one import and one extra constructor argument in probe.ts.
  • All existing callers of probeGateway already handle potential rejections (via .catch(() => null) or surrounding try/catch), so the added synchronous I/O in the Promise executor is safe in all call sites.
  • The test correctly uses vi.hoisted to define mock data before module resolution and adds an assertion verifying that deviceIdentity is forwarded to the client options.
  • The test description "connects with operator.read scope" is now slightly stale — it also verifies deviceIdentity — but this is cosmetic and does not affect correctness.

Confidence Score: 5/5

  • This PR is safe to merge — it is a minimal, well-scoped bug fix with no behavioural changes outside the probe client construction path.
  • The change is a single targeted fix (one import + one constructor argument) with a clear root cause, a regression test covering the new behaviour, and no impact on auth semantics or gateway pairing policy. All callers of probeGateway already handle rejections defensively, so the edge case where loadOrCreateDeviceIdentity could throw on a first-run filesystem failure is covered. No concerns with the test harness setup.
  • No files require special attention.

Last reviewed commit: 83d0dac

@Oclw-bot
Copy link
Copy Markdown
Author

Oclw-bot commented Mar 17, 2026

Thanks — closing this as superseded by upstream commit 4ab016a9b (fix: preserve loopback gateway scopes for local auth).

I independently reproduced the issue locally and this PR fixed it from the reporter side, but upstream already landed the canonical fix in the same area (src/gateway/probe.ts + probe test), so this branch is now redundant/conflicting rather than useful to merge.

@Oclw-bot Oclw-bot closed this Mar 17, 2026
@Oclw-bot Oclw-bot deleted the fix/gateway-status-loopback-device-identity branch March 17, 2026 01:39
This was referenced Mar 18, 2026
Open
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

gateway Gateway runtime size: XS

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@Oclw-bot