Open piotrpietruszka opened 4 days ago
Note that transaction id is generated entirely offline so even if you get the id after u send the transaction, it doesn't necessarily mean it's successful. It takes around 5 seconds for the tx to be finalized hence only after 5 seconds or so, you get the result about the id.
Our sdk basically interacts with the blockchain rpc node to fetch the info about a tx id which is why it says tx not found because the tx has not been finalized.
Or, were u suggestion we make the change what you described at the js sdk level to show it's in pending state? If so, this could be done. Though, if the tx fails, the rpc API would still return it as tx not found error however we could still form the custom failure response at the sdk level again if we want to.
Note that transaction id is generated entirely offline so even if you get the id after u send the transaction, it doesn't necessarily mean it's successful.
Describing the state as PENDING, SUCCESS, FAILD sounds reasonable.
Our sdk basically interacts with the blockchain rpc node to fetch the info about a tx id which is why it says tx not found because the tx has not been finalized.
Though, if the tx fails, the rpc API would still return it as tx not found error however we could still form the custom failure response at the sdk level again if we want to.
From UI, design perspective we are sharing TX ID directly after the creation. For example to check TX in a ledger. Why only finalised TXs can be found? Failed, pending TXs are stored off-chain?
Or, were u suggestion we make the change what you described at the js sdk level to show it's in pending state? If so, this could be done.
Solving this on SDK level can be temporary solution. But keep in mind that even for failed transaction we need similar amount of details as for success one to display to user.
Ah I see what you are getting at. Currently, we do not store failed transactions on ledger. We can definitely make this change so we do start storing all txes on ledger whether successful or failure. Just created a GitHub issue for it: https://github.com/Nuklai/nuklaivm/issues/52
Will make this change before the next reset of our chain. Thanks for elaborating about the use case. I agree it makes sense to store failed transactions on ledger as well.
While the status SUCCESS or FAILED tx will be stored on the ledger, the sdk can handle the PENDING status response as it doesn't make sense to store this on ledger.
Problem
At the moment of the call we know that transaction exists, but instead of returning pending state it is treated as not found.
Current flow
{ "jsonrpc": "2.0", "result": { "txId": "2BXbsTS4K2Era4aXiPSipaPS8aWrRYTatcSmtFxz8onqSrBbU6" }, "id": 3 }
{"jsonrpc":"2.0","id":40,"method":"nuklaivm.tx","params":{"txId":"2BXbsTS4K2Era4aXiPSipaPS8aWrRYTatcSmtFxz8onqSrBbU6"}}
{ "jsonrpc": "2.0", "error": { "code": -32000, "message": "tx not found", "data": null }, "id": 40 }
{"jsonrpc":"2.0","id":68,"method":"nuklaivm.tx","params":{"txId":"2BXbsTS4K2Era4aXiPSipaPS8aWrRYTatcSmtFxz8onqSrBbU6"}}
{ "jsonrpc": "2.0", "result": { "timestamp": 1726236555200, "success": true, "units": [ 224, 7, 14, 50, 26 ], "fee": 321 }, "id": 68 }
{ "jsonrpc": "2.0", "result": { "txId": "2BXbsTS4K2Era4aXiPSipaPS8aWrRYTatcSmtFxz8onqSrBbU6" }, "id": 3 }
or better unify responses (it's very natural that create transaction endpoint will return transaction model):
{ "jsonrpc": "2.0", "result": { "timestamp": 1726236555200, "status": "CREATED", <- NEW FIELD "units": [ ... ], "fee": 321 }, "id": 68 }
{ "jsonrpc": "2.0", "result": { "timestamp": 1726236555200, "status": "PENDING", <- NEW FIELD "units": [ ... ], "fee": 321 }, "id": 68 }
{ "jsonrpc": "2.0", "result": { "timestamp": 1726236555200, "status": "SUCCESS", <- NEW FIELD "units": [ ... ], "fee": 321 }, "id": 68 }