xrpl.js v4.x throws errors on some networks/servers #2872
Description
When connecting to certain networks, Client.connect() throws API version errors. I've observed this with Batch Devnet and Xahau currently.
Tested on: xrpl@4.1.0
Try the following in the node console:
const xrpl = require("xrpl")
const batchClient = new xrpl.Client("wss://batch.nerdnest.xyz")
await batchClient.connect()Expected result: successful connection with no error.
Actual result:
RippledError: invalid_API_version
at RequestManager.handleResponse (/another/devel/workspaces/xrpljs4/node_modules/xrpl/dist/npm/client/RequestManager.js:104:27)
at Connection.onMessage (/another/devel/workspaces/xrpljs4/node_modules/xrpl/dist/npm/client/connection.js:190:37)
at Socket.<anonymous> (/another/devel/workspaces/xrpljs4/node_modules/xrpl/dist/npm/client/connection.js:209:53)
at Socket.emit (node:events:518:28)
at Socket.emit (node:domain:552:15)
at Receiver.receiverOnMessage (/another/devel/workspaces/xrpljs4/node_modules/ws/lib/websocket.js:1220:20)
at Receiver.emit (node:events:518:28)
at Receiver.emit (node:domain:552:15)
at Receiver.dataMessage (/another/devel/workspaces/xrpljs4/node_modules/ws/lib/receiver.js:596:14)
at /another/devel/workspaces/xrpljs4/node_modules/ws/lib/receiver.js:530:12 {
data: {
api_version: 2,
error: 'invalid_API_version',
id: 0,
request: { api_version: 2, command: 'server_info', id: 0 },
status: 'error',
type: 'response'
}
}
It appears that after this error, it is successfully connected, but requests fail unless you explicitly specify api_version: 1 in them.
There should probably be a way to specify in the constructor not to use api_version: 2 in case you're connecting to a server that you know doesn't support API v2. Possibly also, the client should catch the above error and switch to APIv1 mode automatically, or something like that.
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Participants
Activity
tequdev commentedon Jan 11, 2025
This problem can be solved by specifying the apiVersion before connect().
It would be very useful if it could be switched automatically.
nixer89 commentedon Jan 15, 2025
I just stumbled across the same issue (well, I rather wanted to define the
apiVersionin a central place instead of adding it to ever request)I think a nice place would be to add this to the constructor's
ClientOptions:export interface ClientOptions extends ConnectionUserOptionsso one could use:
const client = new Client("wss://test.com", { apiVersion: 1 } )apiVersionoption to Client constructor #2877