inconsistent return on gettransactioninfobyid

[joadr]

Hello,

On my application I'm getting very inconsistent results on the mentioned method, executed as follows:

curl --request POST \
  --url https://api.trongrid.io/walletsolidity/gettransactioninfobyid \
  --header 'content-type: application/json' \
  --header 'user-agent: axios/0.19.2' \
  --data '{"value":"a50fe00d40d55c47b986bd2319a6862ed6b80b48b1d350e10c9029e65fa898f7"}'

Results vary from Status 503 (many of the times), this response:

{
  "id": "a50fe00d40d55c47b986bd2319a6862ed6b80b48b1d350e10c9029e65fa898f7",
  "fee": 4110,
  "blockNumber": 22021865,
  "blockTimeStamp": 1596335172000,
  "contractResult": [
    ""
  ],
  "contract_address": "4163f9f14d5319b7f8822e7771aea45b49e85bb35e",
  "receipt": {
    "origin_energy_usage": 32607,
    "energy_usage_total": 32607,
    "net_fee": 4110,
    "result": "SUCCESS"
  },
  "log": [
    {
      "address": "e42d76d15b7ecd27a92cc9551738c2635c63b71c",
      "topics": [
        "f0f1e23ddce8a520eaa7502e02fa767cb24152e9a86a4bf02529637c4e57504b",
        "0000000000000000000000000000000000000000000000000000000000049ef4",
        "000000000000000000000000837c67bdfacf8c4b7e07286b32654bb987f0d716",
        "0000000000000000000000000000000000000000000000000000000000000000"
      ],
      "data": "000000000000000000000000000000000000000000000000000000000000003200000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000002625a00000000000000000000000000000000000000000000000000000000000000000b00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
    }
  ]
}

and this response (The correct one):

{
  "id": "a50fe00d40d55c47b986bd2319a6862ed6b80b48b1d350e10c9029e65fa898f7",
  "fee": 4110,
  "blockNumber": 22021865,
  "blockTimeStamp": 1596335172000,
  "contractResult": [
    ""
  ],
  "contract_address": "4163f9f14d5319b7f8822e7771aea45b49e85bb35e",
  "receipt": {
    "origin_energy_usage": 32607,
    "energy_usage_total": 32607,
    "net_fee": 4110,
    "result": "SUCCESS"
  },
  "log": [
    {
      "address": "e42d76d15b7ecd27a92cc9551738c2635c63b71c",
      "topics": [
        "f0f1e23ddce8a520eaa7502e02fa767cb24152e9a86a4bf02529637c4e57504b",
        "0000000000000000000000000000000000000000000000000000000000049ef4",
        "000000000000000000000000837c67bdfacf8c4b7e07286b32654bb987f0d716",
        "0000000000000000000000000000000000000000000000000000000000000000"
      ],
      "data": "000000000000000000000000000000000000000000000000000000000000003200000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000002625a00000000000000000000000000000000000000000000000000000000000000000b00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
    }
  ],
  "internal_transactions": [
    {
      "hash": "a053fce001f05d4c78da305d5431eda98e6e5e3dfdacfc6fdd0da8de61d49142",
      "caller_address": "4163f9f14d5319b7f8822e7771aea45b49e85bb35e",
      "transferTo_address": "41e42d76d15b7ecd27a92cc9551738c2635c63b71c",
      "callValueInfo": [
        {}
      ],
      "note": "63616c6c"
    },
    {
      "hash": "51e9d490e8062ba11696011dedfcf1fd58821577c3df7587df865fdfc00f9abe",
      "caller_address": "4163f9f14d5319b7f8822e7771aea45b49e85bb35e",
      "transferTo_address": "41e42d76d15b7ecd27a92cc9551738c2635c63b71c",
      "callValueInfo": [
        {}
      ],
      "note": "63616c6c"
    },
    {
      "hash": "4dceaf53124e1d0342c308897d12b9dfbed39475675eedb7a822df49cd68e99b",
      "caller_address": "41e42d76d15b7ecd27a92cc9551738c2635c63b71c",
      "transferTo_address": "41af16843d1b471364576015e4062cdc3f2628eb62",
      "callValueInfo": [
        {}
      ],
      "note": "63616c6c"
    },
    {
      "hash": "8cb845f4667dc437f574e6a59b5cb9c505270ec49bf4070515d9df8d7d305c35",
      "caller_address": "41e42d76d15b7ecd27a92cc9551738c2635c63b71c",
      "transferTo_address": "410fa13f1920c66d7c9cb476e00557971a7f6bbd54",
      "callValueInfo": [
        {}
      ],
      "note": "63616c6c"
    },
    {
      "hash": "0b5fbfc030e06a0a91cffb02f2414d01e9fce4a2446b9cb6e8abbfc514d7e1dc",
      "caller_address": "410fa13f1920c66d7c9cb476e00557971a7f6bbd54",
      "transferTo_address": "411d0f4031f9e3eeeb727b10e462ab0e59ee06a2a6",
      "callValueInfo": [
        {}
      ],
      "note": "63616c6c"
    },
    {
      "hash": "8e079c03613eb224ff9108b622ead181ad069fd6fc4d2b821790c3b4fc2f1804",
      "caller_address": "411d0f4031f9e3eeeb727b10e462ab0e59ee06a2a6",
      "transferTo_address": "416ce0632a762689a207b9cce915e93aa9596816ca",
      "callValueInfo": [
        {}
      ],
      "note": "63616c6c"
    },
    {
      "hash": "a373e43caf0ee39139cdd17e27cb1964cf59b2bdd13ff7b41485e0203dddd8ee",
      "caller_address": "410fa13f1920c66d7c9cb476e00557971a7f6bbd54",
      "transferTo_address": "414f92846c191c774d761f3949f9794288b3b9a995",
      "callValueInfo": [
        {}
      ],
      "note": "63616c6c"
    },
    {
      "hash": "92dd62a1d1111ed1738b68b67a04d3337547e252dfbc2c5a389d77d09df1432e",
      "caller_address": "41e42d76d15b7ecd27a92cc9551738c2635c63b71c",
      "transferTo_address": "411d0f4031f9e3eeeb727b10e462ab0e59ee06a2a6",
      "callValueInfo": [
        {}
      ],
      "note": "63616c6c"
    },
    {
      "hash": "5307f5b5c4d8a062ecf097439bac04b7426efc0b0a4cafecff4424903fa40cb5",
      "caller_address": "411d0f4031f9e3eeeb727b10e462ab0e59ee06a2a6",
      "transferTo_address": "416ce0632a762689a207b9cce915e93aa9596816ca",
      "callValueInfo": [
        {}
      ],
      "note": "63616c6c"
    }
  ]
}

What could be going wrong? we are having difficulties receiving transactions because of this, and we are spending lots of resources to manually check on tronscan for incoming transactions. Help is very much appreciated.

Thanks, Joaquin

[joadr]

Hello, we are still having this issue, could anybody help us?

[srishti-sk]

One of the members of the Telegram Dev Channels responded as:

trongrid has access frequency restrictions, 15qps, if you need high frequency access, it is recommended to build a local node, you can refer to the document for details https://developers.tron.network/docs/fullnode

Hope this helps. Did u come around with some other solution BTW?

[joadr]

One of the members of the Telegram Dev Channels responded as:

trongrid has access frequency restrictions, 15qps, if you need high frequency access, it is recommended to build a local node, you can refer to the document for details https://developers.tron.network/docs/fullnode

Hope this helps. Did u come around with some other solution BTW?

Status code 503 for a rate-limit is nonsense. It should be 409.

Anyways we sorted this out by stopping receiving TRON via smart contract execution. Before, as soon we found a new block, we went through all transactions and checked if it was TransferContract type or TriggerSmartContract. If the second type, we would make a new request calling the gettransactioninfobyid RPC method in order to check if TRX was sent to any of our addresses. This is what made us make many requests per second. So, we just stopped supporting the TriggerSmartContract method as it seems that less than 0,1% of the transactions we were receiving were not from smart contracts.

The optimal way of doing this anyway, that almost all other blockchains support is getting everything in a single call for each block. For example, on Ethereum, we get all normal transactions & smart contract transactions (aka. Internal Transactions), with the trace_block RPC method, and finally, all tokens transfer with get_logs (that way, for checking if any transactions arrive, we have to call 2 queries per block, instead of having to call per transaction.