Currently you can send a transaction to the RPC and receive back a pending status with a hash. This is great. When you get that transaction it will be not_found. This isn’t great. Imo it should be enqueued while we’re waiting for it to actually be submitted. Reason being currently the not_found status could continue indefinitely. This is odd. I understand there’s a queue system of some sort on the rpc side but not being able to tell the difference between not sent at all and sent and waiting submission and sent but rejected not to be submitted makes it very tricky to rely on the rpc for transaction status. Ideally we’d have two additional statuses to cover the case that a transaction exists on the rpc but hasn’t been submitted to the network and for cases where it was ejected from the queue to ever be submitted.
#Petition to add enqueued and rejected status for transactions sent to the RPC
kindred briar
My guess is most folks expect a successful send resulting in a pending status to eventually resolve to success or failure. The fact this is often the case but not guaranteed is a devx foot gun
deft apex
I'm not sure if you can get much better UX than setting a certain timeout threshold for when to treat 'missing' as 'timed out'
kindred briar
Is the queue system on the rpc or the core side? I.e. does pending mean it’s been sent to the network or just that it’s in some rpc queue prior to being sent to the network?
deft apex
RPC could have its own queueing mechanism, but ultimately the reason for getting the 'missing' status is the fact that it's impossible to tell if validator network still has a tx in memory (as we've discussed in some thread not long ago). it's not just 'a core' - it's the whole network of cores, so I'm not sure if there is more scientific solution to this than a timeout
basically you need to apply some re-submission strategy on the client side (where 'client' is anything external to core) - after not getting the tx included into ledger it could be:
- resubmitted
- sent back to the user with the request to increase the fee (in case if several resubmissions fail)
- abandoned (in case if you're not the client that makes the decision)
maybe there are some other high level strategies and everything here can also be parametrized
IIRC Horizon has some re-submission strategy, but for soroban-rpc the design decision was to move it to the rpc clients. (my memory is a bit vague here though, so take this with a grain of salt)
kindred briar
Ah okay this makes sense. I was under the impression this was an rpc and network thing but actually the rpc isn’t queuing anything it’s just forwarding the tx straight to the network. This makes this a different problem and not one specific to the rpc or Soroban and one to be solved yeah with timeouts and clear rpc documentation. Thanks @deft apex!
autumn cargo
This is the same problem that happens with submissions of txs via Horizon today, except Horizon has smoothed this over by holding open the HTTP connection and returning the result when available to clients.
Unfortunately Horizon "smoothing" this over causes harm, because it's best effort and if that best effort can't be guaranteed you'll end up in the same situation as RPC where you need to go and check the status of the tx yourself where "not found" is a possible outcome.
Horizon's convenient behavior can be harmful because clients get coded to rely on Horizon's synchronous response, and don't get coded to handle the asynchronous cases.