[agent-request] get_ledger_status reports paired:true when WC session is dead at the relay

[szhygulin]

Description

Summary

get_ledger_status returns paired: true based on MCP-side cached WC client state (topic, expiresAt, accounts) without probing whether Ledger Live is still listening on that topic at the WC relay. The session can be dead Live-side (LL restarted, session pruned, user signed out) while the MCP's local view says alive. Subsequent send_transaction calls publish to a topic nobody's listening on, hang/time out, and surface as opaque [object Object] errors.

Repro

1. Pair via pair_ledger_live. Confirm get_ledger_status returns paired: true with topic + expiresAt + accounts.
2. Drop the LL-side session out-of-band (close LL, sign out, or wait long enough for LL to prune it). MCP-side cached state is unchanged — expiresAt is still in the future.
3. prepare_swap → preview_send → send_transaction(confirmed:true).
4. Observe: opaque [object Object] error. LL logs show no session_request for the MCP's topic. Pre-flight get_ledger_status continues reporting paired:true.

Expected

Either:

• (a) get_ledger_status actively probes the relay (or pings Ledger Live via WC wc_session_ping) before claiming paired, returning paired: false or paired: "stale" if the round-trip fails. OR
• (b) Add a liveness: "confirmed" | "unverified" | "failed" field with semantics, and have the agent surface it pre-send so the user knows whether the pin is fresh.

Actual

paired: true based purely on local cached topic / expiresAt. The agent has no signal that the relay is dead until the send fails opaquely.

Why it matters

• Inv v0.2.1: publish to official MCP Registry #9 of the preflight skill instructs the user to confirm the topic suffix in LL → Settings → Connected Apps before the first send. That's a manual step. A live paired field would catch it programmatically.
• The opaque [object Object] error makes diagnosis hard — the user has to dump LL logs and grep for missing session_request to figure out what happened.
• Fix is small: one extra round-trip (wc_session_ping or equivalent) on the get_ledger_status hot path, optionally cached for a few seconds.

Evidence

Real session today (2026-04-30): MCP reported paired=true, topic `282be563ba359c9398b3d810a3c856967ebfb6c2515b69498679a7ae31060570`, expiresAt 1777973736000 (4 days out). Two `send_transaction` attempts on a stETH approve from `0xC0f5…4075` failed with `[object Object]`. LL logs covered the send-time window (last entry 18:41:59 UTC, sends were at ~18:40); no occurrence of `282be563` anywhere; the only successful sign_transaction in the window was an unrelated Safe `approveHash` from `0x4f51…F7CA` at 17:20:38 UTC, on a different WC session.

Category: `bug_report`

Context

• Tool attempted: `send_transaction`
• Chain: ethereum
• Error observed:
  ```
  send_transaction returned opaque [object Object] error twice on the same handle (prepare_swap stETH→ETH approve step). Ledger Live logs (~85min window ending at 18:41:59 UTC) show NO sign_transaction event around the send time and no occurrence of the MCP-reported topic suffix `…31060570` anywhere — the relay round-trip was dead Live-side, but get_ledger_status had reported paired:true with expiresAt 4 days out.
  ```

---

Submitted via the `request_capability` tool in vaultpilot-mcp by an AI agent (Claude Code).

[szhygulin]

Pushing back on the premise before adding code — get_ledger_status already has a multi-layer liveness pipeline that the report doesn't mention, and the proposed fix duplicates it. Worth pinning down the actual failure mode before touching the probe path.

What's already in place (as of main @ 4b1213b):

1. Initial probe at SDK restore — getSignClient() calls verifySessionAlive(c, topic) (src/signing/walletconnect.ts:241) and sets peerUnreachable = liveness !== "alive".
2. 30s background keepalive — startKeepalive (walletconnect.ts:264-281) re-probes every KEEPALIVE_INTERVAL_MS = 30_000 and updates peerUnreachable continuously while the session is live.
3. Per-send probe — requestSendTransaction (walletconnect.ts:885-893) runs a fresh probeSessionLiveness immediately before publishing. On dead/unknown it throws WalletConnectSessionUnavailableError with deadSessionMessage(). This is the issue [agent-request] send_transaction hangs silently when WalletConnect session is disconnected #75 fix.
4. Surfaced flag + guidance — getSessionStatus() (src/signing/session.ts:317-336) emits peerUnreachable: true + the multi-line PEER_UNREACHABLE_GUIDANCE whenever the flag is set.

So adding "an extra round-trip on the get_ledger_status hot path" reproduces what's already there. And the per-send probe at point 3 should have caught a dead relay in your repro path before publishing — it would not have surfaced as [object Object], it would have surfaced as a typed error with an actionable message.

The opaque [object Object] is the actual anomaly. Neither WalletConnectSessionUnavailableError nor WalletConnectRequestTimeoutError should serialize that way — both carry a .message. If the agent saw [object Object], the structured error is being toString'd or JSON-encoded somewhere upstream, or the failure path didn't go through either error class. That's a different bug than "no probe."

Three concrete questions before this becomes a code fix:

1. Was peerUnreachable actually false in the get_ledger_status response at send time? If it was true and the agent ignored it, this is a skill/agent UX issue, not an MCP bug. If it was false despite the relay being dead, the existing 30s keepalive missed it — that's interesting and points at an LL-side ping-vs-sign asymmetry (LL acks WC pings even when its signer subapp can't process eth_sendTransaction), which an additional probe at get_ledger_status would also miss.
2. What did the raw error object look like? A [object Object] rendering with no .message means the error came from somewhere other than requestSendTransaction's probe path — possibly the WC SDK's internal request layer rejecting the topic, or an MCP wrapper that's stringifying via JSON.stringify(err) instead of err.message. That's the actual fix surface.
3. Could you re-run the repro with DEBUG=vaultpilot:wc* (or whatever debug env we expose) and capture the full error stack? Without that, "add another probe" is a guess.

Re-scope options:

• (a) Close as duplicate of [agent-request] send_transaction hangs silently when WalletConnect session is disconnected #75/WalletConnect sessions die repeatedly within minutes — multiple drops per hour-long session, blocking real send flows #241 if you can confirm peerUnreachable: true was in fact present and the agent missed surfacing it.
• (b) Re-scope to "trace [object Object] to its source error class" — small, targeted, and addresses the actual user-facing harm.
• (c) Stronger probe (eth_chainId instead of c.ping) if you can establish that LL acks pings while its signer subapp is dead. That's a different fix than what the issue proposes and would need verification first.

Which path matches the actual failure?

[szhygulin]

closed as redundant