XRPLF / xrpl-dev-portal

Source code for xrpl.org including developer documentation
https://xrpl.org
Other
525 stars 1.01k forks source link

getTransactions example returns error #426

Closed vnistor closed 6 years ago

vnistor commented 6 years ago

The example for getTransactions returns an error: [MissingLedgerHistoryError(Server is missing ledger history in the specified range)]

However, all fields in options are marked as Optional. Which of the fields are required?

mDuo13 commented 6 years ago

The getTransactions method is behaving as intended. However, the server you are querying does not have the necessary transaction history to provide an answer. r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 is an example address that hasn't been used in a few years, so that's why.

rippled servers can be configured to keep differing amounts of history, depending on the needs and capacity of the server. Ripple's general-purpose public server, s1.ripple.com, serves a few months' worth of history only.

For addresses that have been active recently, you should see results as expected.

If you connect to the full-history server s2.ripple.com when you instantiate the API, you'll also see transactions even for addresses that haven't been active for a while.

vnistor commented 6 years ago

I connected to the testnet and queried an address I've been using for testing over the past few days r9XSGfyyNNgWsvfTgWqD1JnyE4e8NCSkWJ.

If I query without any options:

const txs = await api.getTransactions("r9XSGfyyNNgWsvfTgWqD1JnyE4e8NCSkWJ")
    .catch(err => {
      console.error(err);
    });

I get: [MissingLedgerHistoryError(Server is missing ledger history in the specified range)]

However, if I add options, I get the intended result:

const options = {
    "minLedgerVersion": 10136541,
    "earliestFirst": true,
    "types": ["payment"]
  }
  const txs = await api.getTransactions("r9XSGfyyNNgWsvfTgWqD1JnyE4e8NCSkWJ", options)
    .catch(err => {
      console.error(err);
    });

Having to add optional fields to get a response does not seem like the expected outcome to me.

Edit Seems like the call is expecting some sort of indication of ledger version, so probably at least one of the fields marked as optional is required. Or, if an indication of ledger version is not sent, it will try to go back in time further than it has a history and runs into trouble, which sounds like a bug somewhere else.

vnistor commented 6 years ago

You are correct, connecting to s2.ripple.com will return a result. Maybe the boilerplate should be adjusted so that s2 is indicated, instead of s1? Then, the above example will return a result within the boilerplate.

Though, to be honest, I don't understand why the examples are not based off of connecting to the testnet, where development should take place.

mDuo13 commented 6 years ago

The examples look up specific transactions and accounts with known history.

The Test Net is reset often and does not keep a long history, so there are no specific transactions and accounts that can be reliably queried after a reset. Meanwhile, there is no harm in looking up known history in a read-only fashion from the production network.

Also, s2 exists only as a full-history server pool, so you should not use it for general purposes when you do not need old history. Therefore, the examples do not show s2 by default.

mDuo13 commented 6 years ago

As for why your call returns an error, I can't say for sure, but it probably is something like you speculated: with the defaults for all the options you have not provided, ripple-lib cannot provide an authoritative, complete response. This is not a bug: the error you are seeing means that you need to refine your query or ask someone else to get a definitive answer. Providing the optional fields is a way of refining your query. The options are correctly optional because some queries do not require them.

mDuo13 commented 6 years ago

Anyway, I am sorry that the behavior is tricky. It is, to some extent, a necessary piece of the design.

I will keep an eye out for places where the documentation can more clearly explain this sort of problem, but for now, closing this ticket since things are behaving as expected.

webtech2412 commented 4 years ago

I am facing the same issue, i have set up full node on my server. Everything is working but getTansactions is throwing error error - error [ValidationError(instance.options.maxLedgerVersion is not exactly one from [subschema 0],[subschema 1])]

I tried passing "minLedgerVersion" from my getserverinfo function using the completeLedger values but it is not working and giving MissingLedgerHistoryError(Server is missing ledger history in the specified range)]

I observe completeLedger is giving me random values. I tried to split and use min/max ledger version but that is not working as the format is getting changed Somitime it give like this completeLedger ="54873243-54888233,54888334-54888352,54888587-54888604,54888706-54888755,54888921-54888922,54889023-54889061,54889170-54889190,54889347-54889402,54889506-54889562,54889665-54889950,54890141-54890169,54890448-54890460,54890561-54890582,54890694-54890732,54890868-54891060,54891231-54898249"

and some time "completeLedgers": "54873243-54888233,54888334",

How i can resolved this. getTransactions is supposed to work with address only and options are optional but it is not working. Please help.

bennji789 commented 4 years ago

getTransactions doesn't return any data whatsoever for me even after using the options parameter, request just keeps going on forever.... any solution yet?

here's my code: by the way I have tried on s1 and s2, same issue

const address = 'rEb8TK3gBgk5auZkwc6sHnwrGVJH8DuaLh'; const options = { "minLedgerVersion": 10136541, "earliestFirst": true, "types": ["payment"] } rippedApi.getTransactions(address, options).then(transaction => { console.log(transaction) }).catch(err => { console.error(err); });

mDuo13 commented 4 years ago

I think @webtech2412's problem is a different one than the original request. That one is being addressed in #827 .

As for @bennji789's problem, I don't know what's wrong but I have a suspicion that your problem is actually just that it's fetching a lot of data. Looks like over 74,000 payment transactions sent by rEb8TK3gBgk5auZkwc6sHnwrGVJH8DuaLh. Try adding a limit parameter to constrain the results.

For example, I got this code to work:

'use strict'
const RippleAPI = require('ripple-lib').RippleAPI;

const api = new RippleAPI({server: 'wss://s2.ripple.com'});

(async function(){
  await api.connect()

  const address = 'rEb8TK3gBgk5auZkwc6sHnwrGVJH8DuaLh';
  const options = {
    limit: 5,
    earliestFirst: true,
    minLedgerVersion: 33928173
  }
  api.getTransactions(address, options).then(transactions => {
    console.log(transactions);
  }).catch(err => {
    console.error(err);
  });

})()