mirror of
https://github.com/actualbudget/actual.git
synced 2026-07-16 07:04:23 -05:00
[GH-ISSUE #5308] [Bug]: Mobile account ledger very slow to load if there are upcoming transactions #116647
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/actual#116647
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @youngcw on GitHub (Jul 8, 2025).
Original GitHub issue: https://github.com/actualbudget/actual/issues/5308
Verified issue does not already exist?
What happened?
Starting with the mobile running balance PR #5219, the mobile account is very slow to load. It only happens if there are upcoming transactions that need loaded. I tracked down the issue to a loot-core api call. I don't know why its so slow though as the processing inside the call seems to run plenty fast.
Ive isolated the slowness issue to the call to send('run-rules', {transaction}) in the usePreviewTransactions hook. I don't think anything to do with the rules processing is causing the issue, but it may be the send itself. Thats similar to what was happening in the account balance preview. In that fix I removed the send call and directly used aql and the processing became instant, even with the manual cleanup of the data. Im not sure how to remove the send call this time. I tried directly calling the runRules function that actually does the work, but I got CRDT errors, so I stopped pursuing that.
So a way to show this is if you have an account with lots of transactions (takes a bit of effort to load no matter what), compare loading the account on mobile with there are upcoming schedules and when there are no upcoming schedules. When there are no upcoming transactions it loads plenty fast, but is really slow if there are upcoming schedules.
If the slowness cant be fixed, the mobile running balance commit will need to be reverted.
How can we reproduce the issue?
How can we reproduce the issue?
In a budget with large accounts( 1000+ transactions ) and upcoming schedules, open the account in the mobile view. It will be very slow to load.
None
What browsers are you seeing the problem on?
No response
Operating System
None
@ZygarDude commented on GitHub (Jul 14, 2025):
Concur, I'm also seeing this issue. I'm hosting on Pikapods. It doesn't seem to be an issue when loading AB on my laptop browser, however, when I attempt to load via mobile, the memory on my Pikapod will spike to the red and eventually load a local AB version on mobile. I'm able to restart the pod to get the memory back to normal but, for now, I'm only using AB via my laptop. Thx for looking into this, Y'all!
@youngcw commented on GitHub (Jul 14, 2025):
@ZygarDude Try resetting your sync id. The mobile running balance addition has not been added to a release yet, its only on the edge build currently.
@ZygarDude commented on GitHub (Jul 15, 2025):
Thx for replying @youngcw. Unfortunately, that didn't seem to resolve the issue on mobile. I'll just continue using the laptop browser for now.
@Kidglove57 commented on GitHub (Jul 15, 2025):
I'm sure there must be something specific to your set up that is causing this? Trouble is I do not have the expertise to suggest anything beyond the usual clear cache/restart phone!
I have an Actual budget file with over 40 accounts (some open and some closed) and 5 years worth of transactions. This is running on Fly but it performs identically on my old PikaPods hosting. In the "latest" release Actual and its account registers loads instantly for me on mobile (Safari/iOS). The only issue I have is with the "edge" version as already outlined above.
I hope you get to the bottom of this!
@ZygarDude commented on GitHub (Jul 15, 2025):
Hmmmm, yeah, super odd that it was working a week ago but isn't now. I removed the "app" from my phone and even try to visit my PikaPod URL from the phone but that's when the memory increases and blows up. I've cleared the cache and restarted the phone as well. Ah, well. Will just wait and see what happens.