#Testing some concurrent submissions and facing some RPC oddness

20 messages · Page 1 of 1 (latest)

gentle prism
#

I'm testing some concurrent transaction submission, so submitting a lot of requests all at once. I get a successful PENDING state along with a hash but some, usually 1-2 out of 20 get stuck with NOT_FOUND for at least 5+ minutes and never reach a success or failure state. This is odd to me.

keen patio
#

that's entirely possible. PENDING doesn't guarantee that transaction will get included into ledger. it just means that it's in validator's memory. if there is too much traffic, it still can get evicted and never get included

#

e.g. imagine validator holds at most 100 txs in memory. you submit a tx with 100-th lowest fee. it gets accepted and sends you PENDING status back. then, say, after 10ms someone else sends a tx with fee higher than yours, then your tx will get evicted, i.e. dropped by the validator.

gentle prism
#

Imo then the get endpoint for transactions should reflect this. Pending and Dropped vs just Not_Found

keen patio
#

that's not possible/feasible

#

external clients don't know when/if validator drops a transaction. moreover, even if one validator drops it, it's not guaranteed that it hasn't been flooded and accepted by a different validator

#

so the best we can do is interpret NOT_FOUND after a certain number of ledgers as 'dropped'

gentle prism
#

Any idea what's behind the TRY_AGAIN_LATER code?

#

Trying to resubmit "stuck" transactions and getting that status code

keen patio
#

TRY_AGAIN_LATER means that fee is already too low (so you get the flow above, but short-circuited - there is no space to fit your tx and its fee is not high enough to replace any in-memory txs)

gentle prism
#

Got it. Thanks!

keen patio
#

actually I lied here, TRY_AGAIN_LATER is when you have a tx from the same account in the queue

#

for insufficient fee we'd have a dedicated error

novel burrow
#

because the 2 txs will end up in the queue?

keen patio
# novel burrow queue as in I cannot send 2 sequential txs from same account in short space of t...

yes, validators only hold at most one transaction per source account. you can read more about that in the blog post https://stellar.org/blog/developers/proposed-changes-to-transaction-submission

Stellar | Proposed Changes To Transaction Submission

We're proposing a change to transaction submission that will support the scalability and safety of the Stellar network, and that is a necessary prerequisite for Soroban.

novel burrow
#

that way the combination of user + admin key would be different for each user technically allowing multiple txs with same admin key in short space of time?

keen patio
#

authorization in soroban in general and the thread you've mentioned in particular can (and frequently should) be decoupled from the transaction source accounts. transaction source account in a general case is just an account that pays the fees - it doesn't need to have anything to do with the logic being executed. so you can have the tx fees be implemented via channel accounts or maybe fee bump txs, while your business logic would use a separate signature

gentle prism