Atuin cloud sync error

Help
1

Hi,

I have two accounts on atuin cloud sync, to which i’ve been syncing separate sets of machine histories.

I decided to move all my machines to the same account.

What I ran was

$ atuin sync # final sync
$ atuin logout
$ atuin login # entered other account details
...
Re-encrypting local store with new key
Writing new key
Logged in!

$ atuin sync
Uploading 136628 records to 018d41ae893c75e3a80003db1ceb0a85/history
  [00:02:19] [########################################################################################################################################################################################################################################] 136,628/136,628 (0.0s)Uploading 25130 records to 01902c629ce87bf580bab6c8eb46bcaa/history
⠈ [00:00:11] [#########################################################################################################>-------------------------------------------------------------------------------------------------------------------------------] 11,400/25,130 (13.9s)2025-01-06T11:20:38.002302Z ERROR atuin_client::record::sync: failed to post records: There was an error with the atuin sync service: Status 520.
If the problem persists, contact the host

Location:
    /private/tmp/atuin-20240610-8671-h80ut1/atuin-18.3.0/crates/atuin-client/src/api_client.rs:162:9
Error: a request to the sync server failed: "There was an error with the atuin sync service: Status 520.\nIf the problem persists, contact the host"

Location:
    crates/atuin/src/command/client/sync.rs:91:38

$  atuin sync
0/0 up/down to record store
Sync complete! 225628 items in history database, force: false

$ atuin sync -f
Uploading 1 records to 018d41ae893c75e3a80003db1ceb0a85/history
  [00:00:00] [####################################################################################################################################################################################################################################################] 1/1 (0.0s)2/0 up/down to record store
Sync complete! 225629 items in history database, force: true

So syncing of a second machine’s history seems to have failed mid-way. And trying to resync either with sync or sync -f doesn’t appear to redo the operation.

For now i logged out, and logged back into my original account, and syncing the small diff there succeeded.

I’m worried that the sync server might have corrupted data for the history that failed to upload.

What are my best options here? Try to create a new account instead? Use atuin store rebuild / rekey and force sync?

Attempt a store push, from a machine that might have most of the history?

Thanks!

2

I checked the output of atuin store status on another machine that synced the broken state, and it contains 25130 items for the host that failed to sync.

I see the same amount of entries in the records.db store table for that particular host.

I’m not sure how i can verify whether the contents is valid though, given values are encrypted.

I guess there are no debug logs by default to try and ascertain whether some subsequent sync succeeded, or whether the server is now storing corrupted data.

3

I’m not totally sure what the issue is here - are you seeing issues with your data, or just worried that there might be?

You can run atuin store verify to ensure it can all be decrypted OK, and atuin store rebuild history to ensure all data in your store is valid history

It’s really unlikely that you’ll somehow have corrupt data from that sync though

4

I am worried.

I haven’t confirmed yet if there are issues with the data or if it’s missing.

But i am worried because the sync failed mid-way, and subsequent syncs didn’t try to upload the ‘remainder’ so to speak, creating the impression that the server thinks it received all it was promised (see the half-way progress bar from the original error report).

atuin store verify worked fine.

I haven’t tried yet atuin store rebuild history in case the current history gets removed, and fails to be rebuilt due to the partial sync.

I will try to confirm that the data is fine by running
atuin history list --format "{user} {host} {time} - {command}" | ag myhostname > history.txt

on both the original machine and on one of the synced machines, and then diff them, to ensure the data is the same.

5

If you had the shell plugin setup, then the sync would have happened in the background. Once your

atuin sync

command completed, a second sync would have started in a background process and completed from where the first left off

6

But when the initial sync failed, i reran it manually immediately, and it didn’t try to sync the previously failed machine.

Would the shell integration really have already started another try in the background in the span of a few seconds before i tried to do it manually? I thought that only happened on a 1 hour delay by default.

7

There’s a good chance it did!

Have you compared both machines?

8

Yes, i crossed check against 3 machines, and the list of commands was identical according to diff (bar the last few ones).

So looks like it worked out.

Thanks for your support!

1 Like
9

Not a problem, glad it’s ok. Generally sync has been designed to be interruptible, and will recover from errors, loss of connection, etc.

Otherwise, the server has as much validation as possible (the payload is encrypted though) to ensure we’re storing valid information