[Bug]: Time disagreement causes sync to fail without explanation #1566

New Issue

GiteaMirror · 2026-02-28T19:47:20-06:00

GiteaMirror commented

2026-02-28 19:47:20 -06:00

Originally created by @MikeBishop on GitHub (Nov 4, 2024).

Originally assigned to: @MatissJanis, @Copilot on GitHub.

Verified issue does not already exist?

I have searched and found no existing issue
I will be providing steps how to reproduce the bug (in most cases this will also mean uploading a demo budget file)

What happened?

Due to external confluence of circumstances, my laptop wound up being an hour off from the correct time. When Actual attempted to sync, it told me that there was a "problem syncing your changes" but didn't give any information about what the problem was. If the file was deleted locally, attempting to redownload produced this message:

It would be preferable to display something about time disagreement, etc. to point the user in the direction of identifying the failure. I don't think Actual needs to create custom error messages for this specific case, but if the error that appears in the browser console (something about "maximum clock drift exceeded") made it a little higher in the stack, this would have been much easier to find and fix.

Where are you hosting Actual?

Docker

What browsers are you seeing the problem on?

Chrome, Desktop App (Electron)

Operating System

Windows 11

Originally created by @MikeBishop on GitHub (Nov 4, 2024). Originally assigned to: @MatissJanis, @Copilot on GitHub. ### Verified issue does not already exist? - [X] I have searched and found no existing issue - [X] I will be providing steps how to reproduce the bug (in most cases this will also mean uploading a demo budget file) ### What happened? Due to external confluence of circumstances, my laptop wound up being an hour off from the correct time. When Actual attempted to sync, it told me that there was a "problem syncing your changes" but didn't give any information about what the problem was. If the file was deleted locally, attempting to redownload produced this message: ![image](https://github.com/user-attachments/assets/21a708a2-2f15-4624-951c-ab31474e51b6) It would be preferable to display something about time disagreement, etc. to point the user in the direction of identifying the failure. I don't think Actual needs to create custom error messages for this specific case, but if the error that appears in the browser console (something about "maximum clock drift exceeded") made it a little higher in the stack, this would have been much easier to find and fix. ### Where are you hosting Actual? Docker ### What browsers are you seeing the problem on? Chrome, Desktop App (Electron) ### Operating System Windows 11

GiteaMirror added the user interface bug labels 2026-02-28 19:47:20 -06:00

GiteaMirror closed this issue

2026-02-28 19:47:21 -06:00

GiteaMirror commented

2026-02-28 19:47:21 -06:00

@jmuzina commented on GitHub (Jan 31, 2025):

I'm having this issue as well. I have a server hosted on Pika Pods, and a dual boot setup with Ubuntu & Windows 11. I use Firefox to access a web client. I was initially editing the budget on Ubuntu.

I switched to the Windows partition, and began editing my budget. At some point, I noticed that my Windows time was 5 hours ahead the real time (I live in UTC -5 timezone) due to the difference in how Linux & Windows sync their clocks to the hardware clock (see article for more).

I disabled and re-enabled the Windows "Set time automatically" setting to fix my clock.

Then, whenever I make any change in the Actual client, the following toast appears:

Something internally went wrong. You may want to restart the app if anything looks wrong. Please report this as a new issue on Github.

This error is printed to the console:

[Exception] Error: maximum clock drift exceeded 1738304264196 1738286704242 300000
    K kcab.worker.cc739dc2474a9f737cb9.js:16
    r kcab.worker.cc739dc2474a9f737cb9.js:16
    tl kcab.worker.cc739dc2474a9f737cb9.js:16
    r kcab.worker.cc739dc2474a9f737cb9.js:16
    value timestamp.ts:215
    cY index.ts:195
    cY index.ts:189
    c2 index.ts:279
    fT index.ts:705
    g1 transactions.ts:114
    g1 transactions.ts:104

Restarting the server on PikaPods did not help, nor did restarting my computer.

This is probably related to https://github.com/actualbudget/actual/issues/1040

Looks like the error is thrown here:
64df0e107c/packages/crdt/src/crdt/timestamp.ts (L214-L216)

@jmuzina commented on GitHub (Jan 31, 2025): I'm having this issue as well. I have a server hosted on Pika Pods, and a dual boot setup with Ubuntu & Windows 11. I use Firefox to access a web client. I was initially editing the budget on Ubuntu. I switched to the Windows partition, and began editing my budget. At some point, I noticed that my Windows time was 5 hours ahead the real time (I live in UTC -5 timezone) due to the difference in how Linux & Windows sync their clocks to the hardware clock (see [article](https://itsfoss.com/wrong-time-dual-boot/) for more). I disabled and re-enabled the Windows "Set time automatically" setting to fix my clock. Then, whenever I make any change in the Actual client, the following toast appears: ``` Something internally went wrong. You may want to restart the app if anything looks wrong. Please report this as a new issue on Github. ``` This error is printed to the console: ``` [Exception] Error: maximum clock drift exceeded 1738304264196 1738286704242 300000 K kcab.worker.cc739dc2474a9f737cb9.js:16 r kcab.worker.cc739dc2474a9f737cb9.js:16 tl kcab.worker.cc739dc2474a9f737cb9.js:16 r kcab.worker.cc739dc2474a9f737cb9.js:16 value timestamp.ts:215 cY index.ts:195 cY index.ts:189 c2 index.ts:279 fT index.ts:705 g1 transactions.ts:114 g1 transactions.ts:104 ``` Restarting the server on PikaPods did not help, nor did restarting my computer. This is probably related to https://github.com/actualbudget/actual/issues/1040 Looks like the error is thrown here: https://github.com/actualbudget/actual/blob/64df0e107c757d76af19ab6fe414c1114094c6bb/packages/crdt/src/crdt/timestamp.ts#L214-L216

GiteaMirror commented

2026-02-28 19:47:22 -06:00

@egozalor commented on GitHub (Mar 31, 2025):

I'm facing this bug as well.

Re-synced my Windows 10 time to match the new daylight savings time with the Actual desktop app open and now I'm experiencing the same error. I can't sync changes from any device or OS. Restarting the Pikapods server or the computer did indeed not help, nor did going back to the previous time.

Has anyoned found a fix? I'm afraid that my budget file has been permanently affected. I'm no developer, but those comments about the Merkle tree in https://github.com/actualbudget/actual/issues/1040 sound scary.

@egozalor commented on GitHub (Mar 31, 2025): I'm facing this bug as well. Re-synced my Windows 10 time to match the new daylight savings time with the Actual desktop app open and now I'm experiencing the same error. I can't sync changes from any device or OS. Restarting the Pikapods server or the computer did indeed not help, nor did going back to the previous time. Has anyoned found a fix? I'm afraid that my budget file has been permanently affected. I'm no developer, but those comments about the Merkle tree in https://github.com/actualbudget/actual/issues/1040 sound scary.

GiteaMirror commented

2026-02-28 19:47:22 -06:00

@egozalor commented on GitHub (Apr 2, 2025):

Has anyoned found a fix? I'm afraid that my budget file has been permanently affected. I'm no developer, but those comments about the Merkle tree in #1040 sound scary.

I don't know what happened but after a couple of days everything has gone back to normal. I tried editing my budget from my Linux client today, and no error was thrown. Now it works from all other devices, including my Windows install where the error started.

I have no clue what fixed it, but I'm happy to support troubleshooting if I can contribute in any way.

@egozalor commented on GitHub (Apr 2, 2025): > Has anyoned found a fix? I'm afraid that my budget file has been permanently affected. I'm no developer, but those comments about the Merkle tree in [#1040](https://github.com/actualbudget/actual/issues/1040) sound scary. I don't know what happened but after a couple of days everything has gone back to normal. I tried editing my budget from my Linux client today, and no error was thrown. Now it works from all other devices, including my Windows install where the error started. I have no clue what fixed it, but I'm happy to support troubleshooting if I can contribute in any way.

GiteaMirror commented

2026-02-28 19:47:22 -06:00

@justinberry commented on GitHub (May 11, 2025):

I just came across this issue with one of my devices having its time set too far in the future. In general I think the issue is reproducible via:

Given any client of Actual
When the time is too far forward in the future (just set the clock forward manually)
And the client submits anything
Then any subsequent submissions from any client with a time greater than 5 minutes before this incorrect future date will fail to sync.

Hacky fix

Caution

This is a nasty hack I did to get it to work again, I do not yet know the full consequences of doing this, follow this at your own risk. Please back up your data if you think about trying this.

Hack the config variable in timestamp.ts to cover the drift in time:

const config = {
  // Allow 5 minutes of clock drift
  //maxDrift: 5 * 60 * 1000,
  // e.g. 5 days, enough to cover the drift
 maxDrift: 5 * 60 * 1000,
};

Now I will simply wait until until the drift time has elapsed in real time then undo the hack, then I'm hoping it all just works again 🤞

An actual fix?

I'm not too familiar with Merkle trees but I suspect the tree might need reconstruction to fix this properly? Could this be a possible maintenance action that the user could choose to do?

Otherwise I suppose the server might need to act as an authoritative source of time and block anything too far in the future?

Happy to submit a PR to address this.

@justinberry commented on GitHub (May 11, 2025): I just came across this issue with one of my devices having its time set too far in the future. In general I think the issue is reproducible via: Given any client of Actual When the time is too far forward in the future (just set the clock forward manually) And the client submits anything Then any subsequent submissions from any client with a time greater than 5 minutes before this incorrect future date will fail to sync. #### Hacky fix > [!CAUTION] > This is a nasty hack I did to get it to work again, I do not yet know the full consequences of doing this, follow this at your own risk. Please back up your data if you think about trying this. Hack the `config` variable in [timestamp.ts](https://github.com/actualbudget/actual/blob/master/packages/crdt/src/crdt/timestamp.ts#L85) to cover the drift in time: ``` const config = { // Allow 5 minutes of clock drift //maxDrift: 5 * 60 * 1000, // e.g. 5 days, enough to cover the drift maxDrift: 5 * 60 * 1000, }; ``` Now I will simply wait until until the drift time has elapsed in real time then undo the hack, then I'm hoping it all just works again 🤞 #### An actual fix? I'm not too familiar with Merkle trees but I suspect the tree might need reconstruction to fix this properly? Could this be a possible maintenance action that the user could choose to do? Otherwise I suppose the server might need to act as an authoritative source of time and block anything too far in the future? Happy to submit a PR to address this.

GiteaMirror commented

2026-02-28 19:47:22 -06:00

@MikeBishop commented on GitHub (Nov 10, 2025):

Otherwise I suppose the server might need to act as an authoritative source of time and block anything too far in the future?

Yes, I think this is the correct fix. The block occurs too late -- the malformed data is already in the tree by the time the server realizes there's a problem. We need to prevent the submission of updates by a client whose view of time diverges from the server too much, so only clients with a bad clock hit the error rather than only clients with a correct clock.

@MikeBishop commented on GitHub (Nov 10, 2025): > Otherwise I suppose the server might need to act as an authoritative source of time and block anything too far in the future? Yes, I think this is the correct fix. The block occurs too late -- the malformed data is already in the tree by the time the server realizes there's a problem. We need to prevent the submission of updates by a client whose view of time diverges from the server too much, so only clients with a bad clock hit the error rather than only clients with a correct clock.

GiteaMirror commented

2026-02-28 19:47:23 -06:00

@bijeebuss commented on GitHub (Nov 11, 2025):

ok I seem to have gotten myself into this situation. Im running v25.11.0 on both server and client. In the console I see

I did have my timezone set wrong on my Mac but now its fixed and Im still getting this error on all devices

@bijeebuss commented on GitHub (Nov 11, 2025): ok I seem to have gotten myself into this situation. Im running v25.11.0 on both server and client. In the console I see <img width="1440" height="805" alt="Image" src="https://github.com/user-attachments/assets/72e45248-fe1f-4f76-a9dd-43b744f78aad" /> I did have my timezone set wrong on my Mac but now its fixed and Im still getting this error on all devices