transaction_unstable_submitAndWatch fails with large transactions

[josepot]

I tried creating an extrinsic against Westend consisting in a Utility.batch_all call with 1200 System.remark_with_event calls of 1kb each, and I consistently receive the following error:

Error when retrieving the call proof: Call proof query errors:\n- Timeout

The logs.. Also, the code that I ran to get these logs and to test this can be found in this commit of the following repo.

It's worth pointing out that the account doesn't currently have enough funds to pay for that transaction. Therefore, the expected behaviour should be the emission of the invalid event with the "Invalid transaction: Payment" as the reason. Which is what happens when lowering the number of batched calls to 1000 calls of 1kb each, rather than having 1200.

So, I'm guessing that the problem has to do with the validation of the transaction.

[tomaka]

Looking at the logs, when we start asking for the call proof, there's a few packet exchanges, and then smoldot sends several packets of 8222 bytes each, which I assume in the transaction. After these packets have been sent, no incoming data is ever read on the connection, and eventually the call times out.

The packets of 8222 bytes only total to around 150kiB of data. My assumption is that smoldot doesn't send more than that amount because it waits for a Yamux ACK packet before doing so, except that this packet never arrives.

The logs unfortunately stop 20 seconds after sending the transaction. During these 20 seconds we don't read any data back, which is very suspicious.

[josepot]

I repeated the test, but this time I let smoldot run for 3 more minutes after having received the error (so that we can capture more logs). These are the logs of that attempt

And since the previous logs hit a different error, these are the logs of another attempt which hit a timeout error

[tomaka]

Sending large transactions is unfortunately not something that can be easily fixed, due to the existence of a limit to the size of a gossip message.

In the second set of logs, the remote shuts down the connection when this limit is reached, which is the expected behavior.

In the first and third sets of logs, the remote instead simply stops sending anything back altogether. In the third set of logs, we see that it doesn't even try pinging us back. I'm very curious about the reason why this happens, but the logs don't really help figure it out.