Auto-trimming of corrupted blocklog when restoring snapshot

[eosusa]

Copying from the Node Operators TG chat:

as weve discussed, heres my standard process i have to run every few weeks after some nodes crash. blocklog is corrupted due to server crash, snapshot cant repair. have to trim last few 100 blocks with eosio-blocklog and then snap launches properly and proceeds syncing. seems like the snap process could handle that trimming back (to before lib i think) instead of the cryptic error and unknown voodoo of trimming the log manually.

couldnt the snapshot process, upon detection of that error message (it always seems to be something about unpacking the producers) just automatically attempt to either trim those last few 100 blocks automagically or some other way to make the snapshot process fix it?

[matthewdarwin]

FWIW, I don't run into this problem. My blocks.log doesn't seem to be corrupted (it is on zfs).

[eosusa]

this tends to occur when something about the node os itself is crashing, as every single nodeos instance on this server leaves these blocks in the exact same state; have to trim the logs few 100 blocks and snap works perfect then.

point is that if its something that heavily reproducible (by more than just me, ross has to do it too), and the fix is consistent (just trim the blocks back to lib), then seems like the snapshot recovery process should be able to do that for u (or at very least, not give a cryptic producer unpack error and actually suggest to trim the blocklog using leap-util). Something other than looking totally crunched; i deleted MANY full logs i could have repaired over the years now knowing what i know with this quirk.