Trinity fails to switch to "regular" sync upon finishing state sync, then hangs indefinitely

What is wrong?

Upon completing state sync (on Ropsten), Trinity attempts to switch to a “regular” rolling sync, but the expected API does not match the one present.

In the log, notice ^C and the hour-long window in between the timestamps.

Additionally, on subsequent run, starting regular sync fails for the same reason.

    INFO  06-12 19:22:40       state  Scheduler queue is empty, sleeping a bit
    INFO  06-12 19:22:41       state  Finished state sync with root hash 0x469a557209df85602c0488f90865fa15fa486ec3338fd349f80c685955835421
    INFO  06-12 19:22:41        sync  Starting regular sync; current head: #3423335
   ERROR  06-12 19:22:41     service  Unexpected error in <p2p.sync.FullNodeSyncer object at 0x7fd4cdb38a20>, exiting
Traceback (most recent call last):
  File "/home/veox/src/py-evm/p2p/service.py", line 68, in run
    await self._run()
  File "/home/veox/src/py-evm/p2p/sync.py", line 66, in _run
    new_chain = type(self.chain)(self.base_db)
TypeError: __init__() missing 1 required positional argument: 'serializer'
    INFO  06-12 19:22:41      server  Closing server...
    INFO  06-12 19:22:41   discovery  stopping discovery

Wholly optional animal pic

Source: kumaran@peepeth

[gsalgado]

So, AFAIR, the only reason why we have Chain as a trinity-proxied service is because we cannot run Chain.import_block() in the same thread that runs the asyncio event loop because import_block() may block for a long time. The other approach we use to run things in separate processes (a process pool executor) doesn’t work for import_block() because (IIRC) Chain keeps a reference to a LevelDB object, which cannot be pickled.

However, unlike the *ChainDB family, the Chain class is stateful, so having it as a trinity-proxied service doesn’t sound like a good idea. For example, how would this work when the network-sync process is constantly updating its Chain instance as it imports blocks, but the IPC server’s Chain is stuck with the state it was in when the process started. We could probably find ways to workaround that, but my gut feeling is that we need to find an alternative solution

[carver]

Yeah, I’ll bump it to the top of my list. Forgot it was a blocker for a real thing, and not just me poking around.