[Repo Assist] fix(setup): surface actionable error when gateway device-pair plugin is not loaded#747
Conversation
|
Codex review: needs maintainer review before merge. Reviewed June 18, 2026, 5:19 AM ET / 09:19 UTC. Summary Reproducibility: yes. at source level: current main returns retriable raw-output failures for the reported non-zero pairing commands, and the linked user logs show the old gateway emitted the device-pair plugin diagnostic. I did not run a live old gateway reproduction in this read-only review. Review metrics: 3 noteworthy metrics.
Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Merge the narrow diagnostic after redacted affected-gateway proof shows setup stops immediately with upgrade guidance, while leaving the broader rollback/deletion policy tracked in #677. Do we have a high-confidence way to reproduce the issue? Yes at source level: current main returns retriable raw-output failures for the reported non-zero pairing commands, and the linked user logs show the old gateway emitted the device-pair plugin diagnostic. I did not run a live old gateway reproduction in this read-only review. Is this the best way to solve the issue? Yes for the narrow diagnostic: the updated classifier is now specific to device-pair and has step-level regression coverage. The remaining gap is merge proof, not a clear code defect. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 234fa8ff097f. Label changesLabel changes:
Label justifications:
Evidence reviewedWhat I checked:
Likely related people:
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. How this review workflow works
|
clawsweeper
Bot
added
rating: 🧂 unranked krab
…is not loaded When the gateway CLI lacks the device-pair plugin (versions prior to 2026.6.0), 'openclaw nodes list --json' and 'openclaw nodes approve' exit non-zero with output containing 'plugin not found: device-pair'. Previously, AutoApproveNodePairing and AutoApprovePairing returned StepResult.Fail with the raw CLI output and then retried 3 times before reporting a vague failure. After retries the error surfaced as: 'Could not list pending node pairing requests (exit 1): ...' This change: - Adds ApprovalRequestHelper.IsPluginNotFoundError to detect this pattern - Returns StepResult.Terminal (non-retriable) with an actionable message pointing the user to upgrade their gateway to 2026.6.0+ - Covers both the 'list pending' and 'approve' command paths in AutoApproveNodePairing, and the 'approve' command path in AutoApprovePairing - Adds tests for IsPluginNotFoundError in ApprovalRequestHelperTests Relates to #677. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Require the missing-plugin classifier to identify device-pair before returning terminal setup guidance, and cover the pairing approval paths so unrelated plugin failures remain retriable. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
ranjeshj
force-pushed
the
repo-assist/eng-device-pair-plugin-not-found-2026-06-11-8f330ecd7f643284
branch
from
6013bf5 to
a87442e
Compare
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
clawsweeper
Bot
removed
the
merge-risk: 🚨 compatibility
shanselman
deleted the
repo-assist/eng-device-pair-plugin-not-found-2026-06-11-8f330ecd7f643284
branch
2 participants
🤖 This is an automated pull request from Repo Assist.
Relates to #677.
Problem
When a user's gateway CLI is older than 2026.6.0, the
device-pairplugin is not loaded, andopenclaw nodes list --json/openclaw nodes approveexit non-zero with:Previously
AutoApproveNodePairingandAutoApprovePairingreturnedStepResult.Failwith the raw CLI output and then retried three times before ultimately surfacing a vague failure message:The user had no clear indication that the root cause was their gateway version.
Fix
ApprovalRequestHelper.IsPluginNotFoundError(string output)— a lightweight string check for the"plugin not found"substring (case-insensitive).ApprovalRequestHelper.PluginNotFoundMessage— a shared, actionable message text directing users to upgrade to 2026.6.0+.AutoApproveNodePairing→ listing pending requests failsAutoApproveNodePairing→ approval command failsAutoApprovePairing→ approval command failsStepResult.Terminal(non-retriable) so the setup engine stops immediately with a clear message instead of retrying.Trade-offs
The detection is a simple substring match. If a future gateway release changes the error wording, it will fall through to the existing
Failpath (no regression, just loses the improvement). No new dependencies.Test Status
The 1 failure (
Constructor_SetsLocalDataDirFromLocalAppDataRootEnvironment) is pre-existing onmainand unrelated to this change (confirmed by running the same test againstmainwith identical infrastructure). AllApprovalRequestHelpertests, including the 7 newIsPluginNotFoundErrortests, pass.Add this agentic workflows to your repo
To install this agentic workflow, run