chains/manager.go:2757: the manager's Shutdown does not shut down the chains it runs, so no VM's Shutdown is ever called, and ConsensusShutdownTimeout is parsed but never used.
Why it matters. A VM gets no chance to flush or close its database on a graceful stop. Archive nodes are unaffected since 1.37.8/1.37.9 (luxfi/evm#152): they commit per accepted block. Any VM that defers work to Shutdown loses it.
Do not fix this alone. It is coupled to luxfi/database's prefixdb.Close() closing its parent store (filed separately). Once chains are shut down, the first one to stop would close the shared store underneath all the others. The two need to land together, with an explicit rule for who owns and closes the shared DB.
Symptom today. Together with the prefixdb issue, every boot logs detected previous ungraceful shutdown, including after a clean SIGTERM. Found while fixing #152 (luxfi/evm v1.104.55–56).
chains/manager.go:2757: the manager'sShutdowndoes not shut down the chains it runs, so no VM'sShutdownis ever called, andConsensusShutdownTimeoutis parsed but never used.Why it matters. A VM gets no chance to flush or close its database on a graceful stop. Archive nodes are unaffected since 1.37.8/1.37.9 (luxfi/evm#152): they commit per accepted block. Any VM that defers work to
Shutdownloses it.Do not fix this alone. It is coupled to luxfi/database's
prefixdb.Close()closing its parent store (filed separately). Once chains are shut down, the first one to stop would close the shared store underneath all the others. The two need to land together, with an explicit rule for who owns and closes the shared DB.Symptom today. Together with the prefixdb issue, every boot logs
detected previous ungraceful shutdown, including after a clean SIGTERM. Found while fixing #152 (luxfi/evm v1.104.55–56).