We currently have a lot of random general IPC errors or gas estimation errors in the semantics tests.
For reference, here is one of the random IPC errors: https://circleci.com/gh/ethereum/solidity/101004
Possibly related to this issue is my comment here: https://github.com/ethereum/solidity/issues/3825#issuecomment-476172142
Here is one of the random IPC errors with the extended error info: https://circleci.com/gh/ethereum/solidity/102266
The errors are apparently timing or performance issues related to aleth in some way.
The failure is always the eth_getTransactionReceipt method, receiving a result of null where it expects .. I suppose the transaction receipt.
With some work, this can be reproduced locally, by running soltest and aleth, but aleth has to be slowed down somehow, for example using cpulimit
The question is why this check succeeds when the transaction RPC call fails.
andrei is currently looking into this.
Here is a full aleth log of such a failure:
Further information: We call sendTransaction, then we call test_mineBlocks but sometimes the transaction is not yet processed at that point so it wouldn't be part of the mined block.
峁攐ssbile workaround: check with https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_getblockbynumber whether the transaction is processed.
Ah, finally a good lead! Well done! I would call the workaround a fix ;)
I think we have 1-2 tests that might rely on actual block numbers, but I think we can "risk" that.
It wouldn't even change the block numbers... it'd just mean polling one step earlier than we did for old aleth versions - i.e. we have to "wait/poll until aleth actually has packed all sent transactions in the pending block before telling it to mine it". So if this works, it's an actual fix, so let's hope it does :-).
(i.e. the idea was to use eth_getBlockByNumber for the pending block before even starting to mine, since at the moment aleth seems to start mining before having even queued all previously sent transactions)
Oh yeah, that sounds even more like a fix :)
Probably the delay due to the query round-trip will make it work already :)
Probably the delay due to the query round-trip will make it work already :)
That's exactly what we thought as well :>
Oh yeah, that sounds even more like a fix :)
I was still hoping that aleth would provide some syncronous method we can use
With https://github.com/ethereum/solidity/pull/6457 merged we could close this, however, with the next aleth release the eth_flush function can potentially used in place of the new polling mechanism, as in the new version it will have an artifical sleep removed
I'd only close it when we don't have random failures for a week or so anyways ;-).
Next problem:
ASSERTION FAILURE:
- file : RPCSession.cpp
- line : 350
- message: Error on JSON-RPC call: Unknown account.
https://circleci.com/gh/ethereum/solidity/108253 (running #6306)
https://circleci.com/gh/ethereum/solidity/108201 (running #6456)
I think we did it!