Are transaction submissions supposed to be serial?

[mkazlauskas]

LedgerStateQuery messages includes requestId (previously mirror/reflection) and then matches that to detect the appropriate response message.

However submitTx messages do not seem to utilize the same mechanism. Is this by design, assuming that clients will submit only 1 transaction at a time?

[KtorZ]

Indeed; the submitTx / evaluateTx both rely on a different mechanism stemming from the fact that transactions are inherently sequential in Ogmios. They are submitted in the same order as they are received by the server and the response comes in the same order as well. This approach works so long as there's only one thread submitting transactions (which is the case in V8 and other JS engine). This doesn't mean however that you can only submit transactions one by one.

The state queries work in principle in a similar way, but because each query go through the same sockets, it becomes a bit harder to know what handler should handle what response. So the requestId is used mainly as a routing mechanism for handlers.

[mkazlauskas]

Thanks! So if I do Promise.all([submitTx(...), submitTx(...)]) it should never mix up the responses?

[KtorZ]

According to the TC39 specification then yes. Promises are executed in the same order as declared in the iterator. Although for this to work properly, it requires that a response is sent back to the client for each promise; which is why I am looking into --> #346. That one is a little odd.

[mkazlauskas]

I'm wondering if it wouldn't resolve both promises with the same result on the 1st response though 🤔

[KtorZ]

Why would it? Results are bound to events and events are emitted only once.

[mkazlauskas]

Nevermind, got a little confused with the event emitter generator. Thanks again!