[Bug]: Focus is always November 2023 #1051

New Issue

GiteaMirror · 2026-02-28T19:30:04-06:00

GiteaMirror commented

2026-02-28 19:30:04 -06:00

Originally created by @GitOnOut on GitHub (Apr 20, 2024).

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?

I'm hosting Actual on fly.io. No matter what I do, whenever I open Actual, the month of November 2023 is always selected, not the current month.

It happens whenever I open up Actual from fresh:

In a new private window
On my phone
My computer
Etc.
It happens on macOS, Windows 11, Linux (Fedora), and iOS
It happens on Librewolf, Safari (iOS), and Brave Browser

If I reload the page in a browser, it remembers the month I selected. If I delete the tab and open it again, same thing, it remembers which month I selected. But as soon as I quit the browser and restart it, or in a new instance on my phone, or in a private window, it picks November. No matter how many months go by, it's stuck in November.

Interestingly, I have another budget file I created for a friend on my fly.io server a couple months after I first started using Actual. In that budget, the month in focus when Actual first opens is always January 2024.

In short, I have 2 budget files. One created months after the other. On the earliest one, it's always November 2023. In the latest one, it's always January 2024. So maybe that has something to do with it.

If this doesn't get fixed, as time goes on, I fear I'll be scrolling through endless months to get to the current one. Lol.

Where are you hosting Actual?

Fly.io

What browsers are you seeing the problem on?

Firefox, Safari

Operating System

Linux

Originally created by @GitOnOut on GitHub (Apr 20, 2024). ### 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? I'm hosting Actual on fly.io. No matter what I do, whenever I open Actual, the month of November 2023 is always selected, not the current month. ![ActualNov](https://github.com/actualbudget/actual/assets/167612916/5721f1c7-2584-4acc-a4ff-d5fc2a9d9313) It happens whenever I open up Actual from fresh: - In a new private window - On my phone - My computer - Etc. - It happens on macOS, Windows 11, Linux (Fedora), and iOS - It happens on Librewolf, Safari (iOS), and Brave Browser If I reload the page in a browser, it remembers the month **I** selected. If I delete the tab and open it again, same thing, it remembers which month I selected. But as soon as I quit the browser and restart it, or in a new instance on my phone, or in a private window, it picks November. No matter how many months go by, it's stuck in November. Interestingly, I have another budget file I created for a friend on my fly.io server a couple months after I first started using Actual. In that budget, the month in focus when Actual first opens is always January 2024. In short, I have 2 budget files. One created months after the other. On the earliest one, it's always November 2023. In the latest one, it's always January 2024. So maybe that has something to do with it. If this doesn't get fixed, as time goes on, I fear I'll be scrolling through endless months to get to the current one. Lol. ### Where are you hosting Actual? Fly.io ### What browsers are you seeing the problem on? Firefox, Safari ### Operating System Linux

GiteaMirror added the bug label 2026-02-28 19:30:04 -06:00

GiteaMirror closed this issue

2026-02-28 19:30:05 -06:00

GiteaMirror commented

2026-02-28 19:30:05 -06:00

@Kidglove57 commented on GitHub (Apr 20, 2024):

That must be incredibly annoying! I have not seen it reported before.

I have an instance hosted on Fly and another on PikaPods. Both open correctly with the current month. Sounds as if you have already addressed this but I wondered if it is a caching issue?

@Kidglove57 commented on GitHub (Apr 20, 2024): That must be incredibly annoying! I have not seen it reported before. I have an instance hosted on Fly and another on PikaPods. Both open correctly with the current month. Sounds as if you have already addressed this but I wondered if it is a caching issue?

GiteaMirror commented

2026-02-28 19:30:06 -06:00

@MatissJanis commented on GitHub (Apr 20, 2024):

👋 The active month selection comes from local storage. If you are using a fresh session (i.e. incognito) - your local storage would be empty and thus we would fall back to the "current month". Which uses your local clock to calculate this.

Is your local clock correct? Is the date in your browser in April?

Try visiting this site to check if your local clock is correct: https://webbrowsertools.com/timezone/

@MatissJanis commented on GitHub (Apr 20, 2024): 👋 The active month selection comes from local storage. If you are using a fresh session (i.e. incognito) - your local storage would be empty and thus we would fall back to the "current month". Which uses your local clock to calculate this. Is your local clock correct? Is the date in your browser in April? Try visiting this site to check if your local clock is correct: https://webbrowsertools.com/timezone/

GiteaMirror commented

2026-02-28 19:30:06 -06:00

@GitOnOut commented on GitHub (Apr 20, 2024):

According to that website, my local clock is correct. Webbrowsertools says April, Actual says November. It's happening across multiple devices and browsers.
I also checked on iOS and I remembered an important detail. In the mobile view, it says April. But as soon as I switch to landscape view to see the desktop version of Actual, it's November. So at least in the mobile view, this bug isn't happening.

@GitOnOut commented on GitHub (Apr 20, 2024): According to that website, my local clock is correct. Webbrowsertools says April, Actual says November. It's happening across multiple devices and browsers. I also checked on iOS and I remembered an important detail. In the mobile view, it says April. But as soon as I switch to landscape view to see the desktop version of Actual, it's November. So at least in the mobile view, this bug isn't happening.

GiteaMirror commented

2026-02-28 19:30:06 -06:00

@youngcw commented on GitHub (Apr 22, 2024):

Are other user prefs persisting, like the theme or date format settings?

@youngcw commented on GitHub (Apr 22, 2024): Are other user prefs persisting, like the theme or date format settings?

GiteaMirror commented

2026-02-28 19:30:07 -06:00

@GitOnOut commented on GitHub (Apr 22, 2024):

The theme does not persist, but interestingly the date format does persist. I have it set to YYYY-MM-DD.

@GitOnOut commented on GitHub (Apr 22, 2024): The theme does not persist, but interestingly the date format does persist. I have it set to YYYY-MM-DD.

GiteaMirror commented

2026-02-28 19:30:08 -06:00

@MatissJanis commented on GitHub (Apr 23, 2024):

Theme is stored in global prefs (indexeddb). Whereas date format and currently active budget month - in local storage.

So my bet would be that something is going on with your local storage.

I don't know why and how though. Especially because it happens on multiple devices and browsers.

@MatissJanis commented on GitHub (Apr 23, 2024): Theme is stored in global prefs (indexeddb). Whereas date format and currently active budget month - in local storage. So my bet would be that something is going on with your local storage. I don't know why and how though. Especially because it happens on multiple devices and browsers.

GiteaMirror commented

2026-02-28 19:30:08 -06:00

@MatissJanis commented on GitHub (Apr 23, 2024):

Try importing your budget in https://demo.actualbudget.org - does it default to nov there too?

@MatissJanis commented on GitHub (Apr 23, 2024): Try importing your budget in https://demo.actualbudget.org - does it default to `nov` there too?

GiteaMirror commented

2026-02-28 19:30:08 -06:00

@GitOnOut commented on GitHub (Apr 23, 2024):

Imported my budget, and did not get the November bug there! It correctly says April. Tried on both my computer, and mobile phone. No bug.

I also want to say that when I first began to use Actual, which must have been a year ago, this bug was not present. I've only been encountering this since... well, since it became December 2023 and my budget stayed on November. So if something in Actual's code caused this, it would probably have been a change which happened around that time, because I update the app regularly when a new version comes out. Sorry for not reporting this sooner!

@GitOnOut commented on GitHub (Apr 23, 2024): Imported my budget, and did not get the November bug there! It correctly says April. Tried on both my computer, and mobile phone. No bug. I also want to say that when I first began to use Actual, which must have been a year ago, this bug was not present. I've only been encountering this since... well, since it became December 2023 and my budget stayed on November. So if something in Actual's code caused this, it would probably have been a change which happened around that time, because I update the app regularly when a new version comes out. Sorry for not reporting this sooner!

GiteaMirror commented

2026-02-28 19:30:08 -06:00

@Kidglove57 commented on GitHub (Apr 24, 2024):

Just a double check, in view of (a) your success in importing into the Demo and (b) that this issue has not occurred for any other user as yet. Have you followed the below process?
a) taken an up to date export.
b) then fully deleted your existing budget file on Fly
c) then reimported the file that you exported?

@Kidglove57 commented on GitHub (Apr 24, 2024): Just a double check, in view of (a) your success in importing into the Demo and (b) that this issue has not occurred for any other user as yet. Have you followed the below process? a) taken an up to date export. b) then fully deleted your existing budget file on Fly c) then reimported the file that you exported?

GiteaMirror commented

2026-02-28 19:30:09 -06:00

@GitOnOut commented on GitHub (Apr 24, 2024):

Just tried it, twice. It didn't work. Still November.

Reminder: the bug doesn't happen on the mobile view in iOS. Only when I switch to the desktop view by going into landscape mode, does it become November. I wonder why the mobile view is not affected.

@GitOnOut commented on GitHub (Apr 24, 2024): Just tried it, twice. It didn't work. Still November. Reminder: the bug doesn't happen on the mobile view in iOS. Only when I switch to the desktop view by going into landscape mode, does it become November. I wonder why the mobile view is not affected.

GiteaMirror commented

2026-02-28 19:30:09 -06:00

@GitOnOut commented on GitHub (Apr 24, 2024):

I just realized as well that April is always in bold, even when it's November... so my computer must KNOW it's April. Otherwise why would it be bold? It just opens the budget view in November regardless. That must be another clue.

@GitOnOut commented on GitHub (Apr 24, 2024): I just realized as well that April is always in bold, even when it's November... so my computer must KNOW it's April. Otherwise why would it be bold? It just opens the budget view in November regardless. That must be another clue.

GiteaMirror commented

2026-02-28 19:30:09 -06:00

@MatissJanis commented on GitHub (Apr 24, 2024):

Would you be open to DMing me on Discord the link to your server and the passcode so I could debug this on my end?

@MatissJanis commented on GitHub (Apr 24, 2024): Would you be open to DMing me on Discord the link to your server and the passcode so I could debug this on my end?

GiteaMirror commented

2026-02-28 19:30:09 -06:00

@GitOnOut commented on GitHub (Apr 24, 2024):

Done.

@GitOnOut commented on GitHub (Apr 24, 2024): Done.

GiteaMirror commented

2026-02-28 19:30:10 -06:00

@MatissJanis commented on GitHub (Apr 25, 2024):

Ok, thanks to @GitOnOut I managed to reproduce the issue.

Here are the steps:

preliminary requirement: you MUST be using actual-server
create a test budget
switch the active month to sometime in the past
export the budget
close the file
delete the file
import the budget
the date will NOT be the active date, but it will be the past date that was previously selected
change the date to something else
open the budget in a new incognito window: the date will still be in the past

--

What happens here is: we save the local prefs to metadata.json file. This is stored alongside the core sqlite database we use for the product, but the metadata.json file is not synced with the remote server.

When we export a file - it exports all the local prefs in the metadata.json file. This includes the startMonth pref which the user has selected.

When the budget is imported - it gets uploaded to the server. Including the metadata.json file. This is the "default" state that will be used in the future for this budget.

When you open the budget - we download this budget file and store it on the local machine. If the user changes the active date - we update the local metadata.json file, but never update it in the server. Subsequent sessions will use the local metadata.json file.

But then we open the page in incognito: which means there is no local version. So we fall back to the server version. So we download the metadata.json from server where the date is set in the past.

That's the root-cause of the problem and the repro steps. Now we just need to patch it.

@MatissJanis commented on GitHub (Apr 25, 2024): Ok, thanks to @GitOnOut I managed to reproduce the issue. Here are the steps: 1. preliminary requirement: you MUST be using actual-server 2. create a test budget 3. switch the active month to sometime in the past 4. export the budget 5. close the file 6. delete the file 7. import the budget 8. the date will NOT be the active date, but it will be the past date that was previously selected 9. change the date to something else 10. open the budget in a new incognito window: the date will still be in the past -- What happens here is: we save the local prefs to `metadata.json` file. This is stored alongside the core sqlite database we use for the product, but the `metadata.json` file is not synced with the remote server. When we export a file - it exports all the local prefs in the `metadata.json` file. This includes the `startMonth` pref which the user has selected. When the budget is imported - it gets uploaded to the server. Including the `metadata.json` file. This is the "default" state that will be used in the future for this budget. When you open the budget - we download this budget file and store it on the local machine. If the user changes the active date - we update the **local** `metadata.json` file, but never update it in the server. Subsequent sessions will use the local `metadata.json` file. But then we open the page in incognito: which means there is no local version. So we fall back to the server version. So we download the `metadata.json` from server where the date is set in the past. --- That's the root-cause of the problem and the repro steps. Now we just need to patch it.

GiteaMirror commented

2026-02-28 19:30:10 -06:00

@MatissJanis commented on GitHub (Apr 25, 2024):

budgetName is also stored in metadata.json, but it does not have the same problem. That's because we have a special edge-case for it: 469c789c14/packages/loot-core/src/server/main.ts (L1262-L1278)

I wonder if expanding this edge-case scenario so it would save all the local config changes in the same way would be a good solution.

@MatissJanis commented on GitHub (Apr 25, 2024): `budgetName` is also stored in `metadata.json`, but it does not have the same problem. That's because we have a special edge-case for it: https://github.com/actualbudget/actual/blob/469c789c144bb3202add0bec607fbf22c6086426/packages/loot-core/src/server/main.ts#L1262-L1278 I wonder if expanding this edge-case scenario so it would save all the local config changes in the same way would be a good solution.

GiteaMirror commented

2026-02-28 19:30:11 -06:00

@GitOnOut commented on GitHub (Apr 25, 2024):

Congrats on solving the bug!! This was such a pesky annoyance, thank you SO much :D
Though, I still wonder why the mobile view displays accurately lol
Wouldn't it share the same issues regarding the prefs?

@GitOnOut commented on GitHub (Apr 25, 2024): Congrats on solving the bug!! This was such a pesky annoyance, thank you SO much :D Though, I still wonder why the mobile view displays accurately lol Wouldn't it share the same issues regarding the prefs?

GiteaMirror commented

2026-02-28 19:30:11 -06:00

@youngcw commented on GitHub (May 3, 2024):

Would it make sense to just not include the most recent month in metadata.json? I think it would probably be more clear overall to not have that pref persist outside a single client instance.

@youngcw commented on GitHub (May 3, 2024): Would it make sense to just not include the most recent month in metadata.json? I think it would probably be more clear overall to not have that pref persist outside a single client instance.

GiteaMirror commented

2026-02-28 19:30:11 -06:00

@MatissJanis commented on GitHub (May 3, 2024):

Would it make sense to just not include the most recent month in metadata.json? I think it would probably be more clear overall to not have that pref persist outside a single client instance.

You're on the right track. metadata.json is used for all local prefs for storage. So simply removing them from metadata.json would introduce a different problem: where do we persist local prefs? And what's even the purpose of metadata.json if local prefs are moving away from it?

So instead of removing them entirely from metadata.json - I was thinking of leaving them there, but removing them only when performing exports. Alas that was my thought process.. but maybe there is a better solution here I'm not seeing.

@MatissJanis commented on GitHub (May 3, 2024): > Would it make sense to just not include the most recent month in metadata.json? I think it would probably be more clear overall to not have that pref persist outside a single client instance. You're on the right track. `metadata.json` is used for all local prefs for storage. So simply removing them from `metadata.json` would introduce a different problem: where do we persist local prefs? And what's even the purpose of `metadata.json` if local prefs are moving away from it? So instead of removing them entirely from `metadata.json` - I was thinking of leaving them there, but removing them **only** when performing exports. Alas that was my thought process.. but maybe there is a better solution here I'm not seeing.

GiteaMirror commented

2026-02-28 19:30:12 -06:00

@MatissJanis commented on GitHub (May 18, 2024):

Ok, returning back to this.

Here are some further thoughts. Let me know if you agree and I'll start patching this issue.

just removing local prefs from the exported file is a no-go: we have far too many local prefs. Some of which should be removed. And some others - should not be removed. So creating and keeping an up-to-date list of all the "remove this pref" will not scale well.
the other solution is to: update the remote metadata.json file - also not ideal for multi-device users. It would push the prefs of one user, but the other user would never pull them from the server. And if the other user does something - he would override the first user. Resulting in a bit of chaos.
using the CRDT solution for user prefs too? That would solve the sync issue between multiple devices/users. But it gets really annoying if you want to have slightly different preferences between the devices (i.e. viewing last year in desktop device and then opening up mobile to add a new transaction - you would still be viewing last year)
splitting LocalPrefs - we could split the local prefs in two - MetadataPrefs and LocalStoragePrefs (naming TBD); The metadata prefs (budget name, cloud file id, etc.) would still be stored in metadata.json. Whereas the local storage prefs would be fully local - stored in local storage. Thus no conflicts between devices.

Personally I'm leaning towards (4). Let me know your thoughts!

@MatissJanis commented on GitHub (May 18, 2024): Ok, returning back to this. Here are some further thoughts. Let me know if you agree and I'll start patching this issue. 1. just **removing local prefs from the exported file** is a no-go: we have [far too many local prefs](https://github.com/actualbudget/actual/blob/master/packages/loot-core/src/types/prefs.d.ts#L11). Some of which should be removed. And some others - should not be removed. So creating and keeping an up-to-date list of all the "remove this pref" will not scale well. 2. the other solution is to: **update the remote metadata.json file** - also not ideal for multi-device users. It would push the prefs of one user, but the other user would never pull them from the server. And if the other user does something - he would override the first user. Resulting in a bit of chaos. 3. **using the CRDT solution for user prefs** too? That would solve the sync issue between multiple devices/users. But it gets really annoying if you want to have slightly different preferences between the devices (i.e. viewing last year in desktop device and then opening up mobile to add a new transaction - you would still be viewing last year) 4. **splitting LocalPrefs** - we could split the local prefs in two - `MetadataPrefs` and `LocalStoragePrefs` (naming TBD); The metadata prefs (budget name, cloud file id, etc.) would still be stored in `metadata.json`. Whereas the local storage prefs would be fully _local_ - stored in local storage. Thus no conflicts between devices. Personally I'm leaning towards (4). Let me know your thoughts!

GiteaMirror commented

2026-02-28 19:30:12 -06:00

@MatissJanis commented on GitHub (Sep 21, 2024):

This has now been solved in the edge version.

@MatissJanis commented on GitHub (Sep 21, 2024): This has now been solved in the `edge` version.