fix(gateway): expose runtime version in gateway status#73225
Conversation
Greptile SummaryThis PR exposes the gateway runtime version in Confidence Score: 4/5Safe to merge; the one finding is a P2 semantic inversion in version-source priority that has no practical impact when both sources are present. P2-only finding: the fallback chain in probe.ts places statusRuntimeVersion (RPC payload) at higher priority than authProbe.server.version (probe handshake), opposite to the stated intent. In practice both sources report the same version for the same running gateway, so this has no observable impact today. All other changes are straightforward and well-tested. src/cli/daemon-cli/probe.ts — version source priority order on the requireRpc path. Prompt To Fix All With AIThis is a comment left during a code review.
Path: src/cli/daemon-cli/probe.ts
Line: 90
Comment:
**Version source priority is inverted from stated intent**
The PR description says "`statusRuntimeVersion` is a fallback when handshake metadata is unavailable", but the current operator precedence in `statusRuntimeVersion ?? result.authProbe?.server?.version ?? null` makes `statusRuntimeVersion` (RPC payload) the *primary* source and the probe handshake metadata the fallback. If the two sources ever diverge (e.g. a rolling deployment mid-flight), the RPC version wins silently. Per the stated intent the order should be reversed: prefer the more direct handshake metadata and fall back to the RPC payload.
```suggestion
version = result.authProbe?.server?.version ?? statusRuntimeVersion ?? null;
```
How can I resolve this? If you propose a fix, please make it concise.Reviews (1): Last reviewed commit: "fix(gateway): expose runtime version in ..." | Re-trigger Greptile |
fa3a41a to
95b870a
Compare
|
💡 P2 Codex review Needs real behavior proof before merge Workflow note: Future ClawSweeper reviews update this same comment in place. How this review workflow works
ℹ️ INFO Summary Review the changed behavior The branch propagates the Gateway runtime version from handshake metadata or the status RPC payload into Reproducibility: yes. from source inspection, but not from a live run in this review. Current main exposes ℹ️ INFO PR rating Rate readiness from proof and patch quality Overall 🦪 silver shellfish with proof 🧂 unranked krab and patch quality 🐚 platinum hermit.
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. 💡 P2 Real behavior proof Assess whether proof is merge-ready Needs real behavior proof before merge: The PR reports tests and checks, but lacks after-fix terminal output, logs, screenshot, recording, or artifact from a real 💡 P2 Risk before merge Resolve the remaining merge risk
Maintainer options:
ℹ️ INFO Next step before merge Take the next merge decision Manual review is the right lane because the PR has a protected maintainer label and needs contributor-provided real behavior proof rather than an automated code repair. ✅ DONE Security No security blocker found Cleared: The diff only changes CLI status data plumbing, docs, changelog, and tests; it does not add permissions, secret handling, dependencies, install scripts, or new network surfaces. Review detailsBest possible solution: Land this PR or an equivalent small patch after maintainer review and redacted real Do we have a high-confidence way to reproduce the issue? Yes from source inspection, but not from a live run in this review. Current main exposes Is this the best way to solve the issue? Yes, the proposed shape is the narrow maintainable fix: reuse existing handshake metadata and status RPC Label changes:
Label justifications:
What I checked:
Likely related people:
Codex review notes: model gpt-5.5, reasoning high; reviewed against 9eee202a694b. ClawSweeper 🐠 · reviewed against 7eb423e. |
|
Applied the requested compatibility update in What changed:
Local verification before push:
CI is running on the updated PR head now. |
|
ClawSweeper PR egg 🎁 Pass real behavior proof to wake the egg and unlock a hatchable treat. Where did the egg go?
|
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
Landing verification for Local/source proof:
CI/proof:
Known proof gaps:
|
Summary
Describe the problem and fix in 2–5 bullets:
openclaw gateway status/ MCPgateway_statuscould not reliably surface the running gateway version in all probe paths.gateway statusnow carries a version field through daemon probe/gather/print paths, including a read-probe fallback tostatus.runtimeVersionwhen hello metadata is unavailable.Change Type (select all)
Scope (select all touched areas)
Linked Issue/PR
Root Cause (if applicable)
For bug fixes or regressions, explain why this happened, not just what changed. Otherwise write
N/A. If the cause is unclear, writeUnknown.status.runtimeVersion.Regression Test Plan (if applicable)
For bug fixes or regressions, name the smallest reliable test coverage that should catch this. Otherwise write
N/A.src/cli/daemon-cli/probe.test.ts,src/cli/daemon-cli/status.gather.test.ts,src/cli/daemon-cli/status.print.test.ts,src/cli/daemon-cli.coverage.test.tsUser-visible / Behavior Changes
openclaw gateway statustext output can showGateway version: <version>when probe data provides it.openclaw gateway status --jsonincludesgateway.versionwhen probing is enabled (including read-probe fallback fromstatus.runtimeVersion).Diagram (if applicable)
Security Impact (required)
Yes/No) NoYes/No) NoYes/No) NoYes/No) NoYes/No) NoYes, explain risk + mitigation: N/ARepro + Verification
Environment
Steps
openclaw gateway status --json(or--require-rpc) where status RPC succeeds.gateway.versionand text output.Expected
status.runtimeVersionfallback.Actual
Evidence
Attach at least one:
Snippets:
pnpm test src/cli/daemon-cli/probe.test.ts(pass)pnpm check:changed(pass)Human Verification (required)
What you personally verified (not just CI), and how:
Review Conversations
If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.
Compatibility / Migration
Yes/No) YesYes/No) NoYes/No) NoRisks and Mitigations