[Bug]: Focus is always November 2023

[GitOnOut]

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

[Kidglove57]

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?

[MatissJanis]

👋 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/

[GitOnOut]

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.

[youngcw]

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

[GitOnOut]

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

[MatissJanis]

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]

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

[GitOnOut]

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!

[Kidglove57]

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?

[GitOnOut]

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]

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.

[MatissJanis]

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?

[GitOnOut]

Done.

[MatissJanis]

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.

[MatissJanis]

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:

actual/packages/loot-core/src/server/main.ts

Lines 1262 to 1278 in 469c789

	handlers['save-prefs'] = async function (prefsToSet) {
	const { cloudFileId } = prefs.getPrefs();
	// Need to sync the budget name on the server as well
	if (prefsToSet.budgetName && cloudFileId) {
	const userToken = await asyncStorage.getItem('user-token');
	await post(getServer().SYNC_SERVER + '/update-user-filename', {
	token: userToken,
	fileId: cloudFileId,
	name: prefsToSet.budgetName,
	});
	}
	await prefs.savePrefs(prefsToSet);
	return 'ok';
	};

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.

[GitOnOut]

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?

[youngcw]

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.

[MatissJanis]

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]

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. 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!