Votes for amendments not persisting

[alloynetworks]

Issue Description

Multiple validators have noted that the votes using rippled feature AMENDMENTID accept/reject do not persist after restart of rippled

Steps to Reproduce

Restart rippled and check output of rippled feature. It may not match current votes that operator has registered.

Expected Result

Aside from the first run where rippled migrates from the rippled.cfg file into wallet.db, additional accept/reject should be stored in wallet.db

Actual Result

Votes do not persist in wallet.db after restart

Additional information

This issue has been discussed with @nbougalis and warrants further examination to confirm/deny. If this bug does indeed exist, a fix needs to be merged into the next release, else votes for amendments not yet activated will change either for/against depending on the default.

[rippleitinnz]

This happened to me last night after I restarted my server. All 4 current votes to 'accept' amendments, that had previously been cast, failed to persist and returned to the default of 'reject' on restart. The votes have had to be cast again.

[WietseWind]

I had the same thing. I moved bare metal and moved wallet.db along. All votes had to be put in again. I tried to reproduce by simply restarting the validator and indeed: votes gone again. It seems not to persist the votes.

[jonaagenilsen]

I had an old timestamp on /var/lib/rippled/db/wallet.db..

I reversed a vote with
/opt/ripple/bin/rippled feature B2A4DB846F0891BF2C76AB2F2ACC8F5B4EC64437135C6E56F3F859DE5FFD5856 reject # 1.9.1 ExpandedSignerList

then re-enabled it again with
/opt/ripple/bin/rippled feature B2A4DB846F0891BF2C76AB2F2ACC8F5B4EC64437135C6E56F3F859DE5FFD5856 accept # 1.9.1 ExpandedSignerList

So from my observation, timestamp (and contents?) seem to update wallet.db atleast. Possible there's an issue with reading /var/lib/rippled/db/wallet.db properly after a daemon-restart?