Reported here: #10244 (comment)
Travis log here: https://travis-ci.org/bitcoin/bitcoin/jobs/361243719#L2810
Note the JSON exception:
0test_framework.authproxy.JSONRPCException: The mempool was not loaded yet (-1)
That exception was introduced here: https://github.com/bitcoin/bitcoin/commit/cb1e319fe9e198c9c5cf5236fe9af5a3d748b9e8#diff-a0c8f511d90e83aa9b5857e819ced344R1617
cc @jtimon
The transaction are probably successfully added to the mempool, otherwise the assertion would fail https://github.com/bitcoin/bitcoin/blob/c564424d98b1561f16e633528172b3583719e5f3/test/functional/mempool_persist.py#L94
I suspect, it is a race where LoadMempool is still running/about to finish.
Short term fix: when it gets that exception, it should probably retry instead of giving up.
Longer term this would be a reason to prefer using a mutex to avoid preliminary or concurrent access to the mempool dump instead of returning an error. The RPC could just wait.
Referencing @MarcoFalke comment in #12842 (comment):
I think we had reports that loading the mempool took 1.5 hours or so, just noting without further comment.
Could we have the test framework wait for mempool to load?
The test case already waits for the mempool to load; it checks it via len(n.getrawmempool())==5, but I guess the problem is that between loading the 5th tx and updating the global flag, it also releases cs_main, reprioritises transactions, and notes a couple of log entries, which is enough time for python to race on and try saving the mempool data.
FWIW, adding MilliSleep(200); just before the final LogPrintf in LoadMemPool looks like it reproduces the problem pretty reliably to me.
Fixing that problem gives another though: there’s a check for “Unable to dump mempool to disk” further on, which can also give the “mempool was not loaded yet” error. That can be worked around too, but maybe it would be better to just make the g_is_mempool_loaded flag visible via getmempoolinfo so the tests can wait accurately?