If anyone experiencing this issue could try the new sync, released as opt-in for v18, that would be great!

Requirements

1. All clients will need to be running the same version (>=v18)
2. Any servers will need to be running at least v18

Setup

1. Add this to the bottom of your ~/.config/atuin/config.toml

[sync]
records = true

1. Run atuin sync

2. If prompted by (2), run atuin history init-store to import old data to the new sync

At any time, run atuin store status to see what’s going on with your stores.

You will need to repeat these steps for every machine running Atuin

Troubleshooting

If you run into any error about keys with the new sync, please run atuin store verify and report back.

More info: https://forum.atuin.sh/t/sync-v2-testing/124

Have you got any examples of ordering that does/doesn’t work? 🤔

Fwiw, I’m totally reworking sync in #1400, which will be opt-in for v18. It should be much, much less sensitive to this kind of thing 🙏

Thanks for the walk through on the purge process. That right there seems to be the missing magic to recover from bad scenarios that v1 sync never had.

I now have 5 machines all connected with the purged record based history and their stores verify.

Somewhat to my confusion atuin store status is now showing 6 hosts: 1 of them of course not being the “current host” anywhere. Guessing from timestamps I guessing this was from a failed attempt with the 3rd machine in my nuke-and-pave I did to get rid of cloned hosts earlier. Is there a way to purge entries marked with a specific host just to keep things tidy since it only has a couple useless entries and won’t be coming back? No great harm in staying I guess it’s just a bit confusing to identify.

In any event at least for my problematic cases there is now a way out to a clean usage with the record based store. 💯

So far I have 4 hosts hooked up and migrated to the v2 records. I actually have 4 hosts identified in the store status now as well as all the old history. This is better than I’ve ever been able to accomplish before v18 + v2 records.

Glad it got this far. Fwiw, the hostid used for the store does not have any relation to what’s within the history itself. I’ve tried to decouple the two as much as possible to reduce brittleness.

Failed to verify local store encryption: attempting to decrypt with incorrect key.

Afaik this occurs with one of two things, seen by the kids shown

1. At some point in the past, this machine had a different key to the others, so was writing history with the wrong key
2. At present, this machine has the wrong key

Once you’ve verified that all keys on all machines are correct, you can resolve the error with the following operations. It’ll make life easier if you disable auto_sync temporarily.

To be extra safe, make a copy of ~/.local/share/atuin.

1. atuin store purge - this will delete all records in the store that cannot be decrypted with the current key
2. atuin store verify - verify that the previous operation was successful
3. atuin store push --force - this will delete all records stored remotely, and then push up local data. Run this on the machine that has been purged
4. atuin store pull --force - this does the opposite to (3). Delete all local data in the store, and pull from the remote
5. atuin store rebuild history - ensure your history.db is up to date after all these operations

The idea in the recovery there is to correct the store on one machine, and then ensure that all others match it. While it does delete data, it only deletes data that cannot be decrypted.