[pdp2121]

High Level Overview of Change

Replaces xrpl-client with xrpl.js in the backend (server/lib/rippled.js) and adds recovery for a stalled ledger stream. This fixes pods silently serving frozen ledger metrics (DGE-5078).

• Use the xrpl Client and re-subscribe to the ledger stream on every (re)connect.
• Watchdog: if no ledger arrives for 60s, replace the connection and move to the next host in VITE_RIPPLED_HOST, if more than one is configured.
• /api/v1/metrics returns {} (shown as --) when metrics are older than 60s, instead of stale values.
• Restart the 50-ledger window after a gap so post-reconnect metrics aren't skewed.
• Log errors from the ledger handler instead of losing them.
• Remove the unused P2P connection and getAccountInfo / getBalances / getOffers. The server doesn't call them; the frontend has its own copies.
• Move xrpl from devDependencies to dependencies. No version change.
• Also, cleaned up some unnecessary debug messages printed out in log.info

Context of Change

A staging pod (h46tx) stopped receiving ledgers on Oct 18 and served frozen metrics for days; prod had the same issue in Aug 2025. Root cause:

• The connection to rippled went silent without closing. xrpl-client's inactivity timer called close().
• The underlying websocket package only half-closes the socket (socket.end(), never destroy()), and the peer never sent its FIN.
• So the close event never fired, and xrpl-client (which only reconnects on close) never reconnected.

xrpl.js uses ws, which destroys the socket after its close timeout, and pings every 20s. The watchdog also covers cases a ping can't detect (lost subscription, unsynced node, failed first connect). The frontend still uses xrpl-client and isn't affected: browsers use the native WebSocket, which doesn't have this bug.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• Tests (You added tests for code that already exists, or your new feature included in this PR)

Before / After

• Before: a dropped connection left the pod stuck forever (online: false, no reconnect) and serving its last metrics until a redeploy.
• After: the pod reconnects about 60s after the last ledger, and /api/v1/metrics returns {} (shown as --) while the data is stale.
• Log line: Rippled client: now logs endpoint, connected, lastLedgerIndex and secSinceLastLedger.
• New log messages: No ledger from … reconnecting, Connected to …, Disconnected from ….

Test Plan

• Local repro: a TLS mock rippled behind a proxy that silently drops the connection and never sends its FIN.
  • Old code: stuck forever with frozen metrics; the same log signature as the staging pod.
  • New code: reconnects about 61s after the last ledger, metrics are correct right away, and the dropped client never reconnects on its own (200s run).
• Startup race: getAMMInfo() called immediately after load, which used to fail with readyState 0 (CONNECTING), now returns the fee."

[ripple-code-reviewer]

No issues found.

[ripple-code-reviewer]

No issues found.