Alden Hu

yeah I feel safer knowing it's compatible with an even older tag than a small increment.

4h2m 16 processes, replay_concurrency_level=4: https://gist.github.com/msmouse/8422c39c620af1dd4b29c9c224beef9e (the current setting, just with better machine) 4h22m 48 processes, replay_concurrency_level=2: https://gist.github.com/09a40104a4d317be8d7b7042d4f54056 (I see some huge overlaps between partitions) 4h40m 32 processes, replay_concurrency_level=2: https://gist.github.com/79d8a92fbdf45471a7fbd8444075724a

so the real issue is we are missing a few (tens of :trollface: ) epoch ending backups between epoch [954, 1030] inclusive. gonna put in some backups manually and see...

after creating several manual snapshots: 3h40m 32 processes, concurrency=2 https://gist.github.com/c18f0d8a5f9492a40f342a202fd1fd0e can still use a few more snapshots since the last run still replayes a few millions in vein https://gist.github.com/msmouse/0df0e8d7836a58474094d545a8eb741a 3h25m...

Do you think it's worth printing out the entire proof no matter which part of the verification failed? (or even verify in place that the proof adds up itself)

strum? We used to use it, but stopped doing so and worked around it as part of the external dependency removal effort. https://docs.rs/strum/latest/strum/derive.AsRefStr.html

Issue has been fixed. Thanks @niklasf

* **#12864** 👈 * **#13043** * **#13034** * **#13033** * `main` This stack of pull requests is managed by Graphite. Learn more about stacking. Join @msmouse and the rest of...

We are abandoning manual ranges? I think we had them because different periods in the history replays at dramatically different speed?

* **#13164** 👈 * `main` This stack of pull requests is managed by Graphite. Learn more about stacking. Join @msmouse and the rest of your teammates on Graphite