Opentonapi simplifies development of TON-based applications and provides an API centered around high-level concepts like Jettons, NFTs and so on keeping a way to access low-level details.
MIT License
120
stars
23
forks
source link
Transactions details are not returned from `liteserver/list_block_transactions` #353
I'm using TONAPI liteserver method to receive the transactions inside the block. But TONAPI server does not return requested information on transactions. No hash, account_id or lt is returned, even though they should according to the mode I'm passing.
As an example, I try to request transactions with following params:
As one can see, tx hashes, accounts and lts are present. Moreover, the proofs are exactly the same between public liteservers and TONAPI. Which means that internally the data are correct on the TONAPI side.
But for some reason TONAPI call does not return necessary tx details.
I would be very grateful if someone (@zakhar-petukhov @mr-tron @aleksej-paschenko ) can help/share the experience on this issue as this is pretty critical for my use-case.
Hi!
I'm using TONAPI liteserver method to receive the transactions inside the block. But TONAPI server does not return requested information on transactions. No hash, account_id or lt is returned, even though they should according to the mode I'm passing.
As an example, I try to request transactions with following params:
I tried with many different libs, but below is the example
curl
request to eliminate any possible library issues:The answer is
If I make exactly the same request to public liteservers, e.g., using
pytoniq
Then I get the following output:
As one can see, tx hashes, accounts and lts are present. Moreover, the proofs are exactly the same between public liteservers and TONAPI. Which means that internally the data are correct on the TONAPI side.
But for some reason TONAPI call does not return necessary tx details.
I would be very grateful if someone (@zakhar-petukhov @mr-tron @aleksej-paschenko ) can help/share the experience on this issue as this is pretty critical for my use-case.