mirror of
https://github.com/actualbudget/actual.git
synced 2026-07-16 07:04:23 -05:00
[GH-ISSUE #2705] [Bug]: Desktop app on macOS budget loading error #70817
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/actual#70817
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 @Stryd3r on GitHub (May 4, 2024).
Original GitHub issue: https://github.com/actualbudget/actual/issues/2705
Verified issue does not already exist?
What happened?
I successfully downloaded the desktop app on my Mac and when I connect to my fly.io account and load the budget I’m getting an error. Errors are “We had an unknown problem opening “My Finance dcb1c51” and I’m also unable to browse to the exported .json file. Occasionally I’m also getting the “something went wrong trying to download that file error”.
Additional information:
I’m facing this issue on- Client version: v24.5.0
Server version: v24.5.0
Screenshots attached.
Where are you hosting Actual?
Fly.io
What browsers are you seeing the problem on?
Safari
Operating System
Mac OSX
@cjtodaro commented on GitHub (May 4, 2024):
I'm having the same issue. Trying to run desktop app on MacOS 14.4.1. ActualBudget hosted on unRAID 6.12.8
The error message file name doesn't match the budget file I'm trying to open either.
@FeralFlora commented on GitHub (May 4, 2024):
I have a similar issue on Windows 11, but in my case, the download load screen just goes on forever:
My Actual server is hosted on Pikapods, and the server version is 24.4.
@lukebouch commented on GitHub (May 4, 2024):
I'm having the same issue.
@moobaabaa commented on GitHub (May 5, 2024):
Same with desktop app. Browser access works fine.
Self-hosted (local)
Apple M1 Mac mini
Sonoma 14.1.1
@youngcw commented on GitHub (May 6, 2024):
Can someone try out the build available here and confirm if its working for you or not? https://github.com/actualbudget/actual/actions/runs/8971187425?pr=2715
It should fix the loading issue. You will need to download the file listed as "actual-electron-macos-latest". That is a zip file that contains the desktop app.
@cjtodaro commented on GitHub (May 6, 2024):
That fixed it for me!
@moobaabaa commented on GitHub (May 7, 2024):
Excellent! Thanks for the updated file. Works for me.
@psybers commented on GitHub (Jun 5, 2024):
This seems to be broken again.
@MatissJanis commented on GitHub (Jun 5, 2024):
Ok, so I'm really confused. Building the desktop app locally works just fine. Building the same source via CI/CD - creates a broken build.
Code signing and other things are all turned off. So I'm really lost as to what is going on which makes it very hard to debug and patch the issue.
@youngcw commented on GitHub (Jun 5, 2024):
@MatissJanis Could you upload a good working build to the release? That way people can use it while we try to determine why the autobuild is broken.
@MatissJanis commented on GitHub (Jun 5, 2024):
Good idea. Uploaded my local build to the release as a temporary solution: https://github.com/actualbudget/actual/releases/tag/v24.6.0
@MatissJanis commented on GitHub (Jun 5, 2024):
@youngcw had a brilliant idea: the issue might have to do with the Github CI runners.
Here's a CI job that was building a working artefact: https://github.com/actualbudget/actual/actions/runs/8971187425/attempts/1
So I re-ran the same exact job and it failed: https://github.com/actualbudget/actual/actions/runs/8971187425/attempts/2
This points to the issue being in the runner. Now we just need to figure out what changed and how to change it back.
@psybers commented on GitHub (Jun 6, 2024):
@MatissJanis I would guess the issue is the non-pinned OS version:
The passing run:
and the failing run:
What exactly changed in macOS that is causing the issue, I do not know. But other than that, and the fact the artifact size is slightly different, I do not spot any differences in the logs of the two runs.
@MatissJanis commented on GitHub (Jun 6, 2024):
Any ideas how to pin to a specific runner version?
@youngcw commented on GitHub (Jun 6, 2024):
Looks like we can only pin to major versions so even if we specified macos-14 we would probably still have the same issue
@youngcw commented on GitHub (Jun 6, 2024):
Maybe this project could help. https://github.com/pd4d10/debugtron
@psybers commented on GitHub (Jun 6, 2024):
AFAIK you can not. You can only select major release, e.g.
-13or-14instead of-latest.@psybers commented on GitHub (Jun 6, 2024):
I used the debugtron and see this when opening a local file:
@psybers commented on GitHub (Jun 6, 2024):
Have we ever confirmed if the mac images fail on both Intel and M1/M2 macs? I am on an Intel mac.
GitHub's latest macos image is arm only.
@MatissJanis commented on GitHub (Jun 6, 2024):
I'm on Intel too.
@cpisto commented on GitHub (Jun 6, 2024):
I'm on Apple silicon and the original released 24.6.0 image fails for me, suggesting it is not an architecture specific issue.
@MatissJanis commented on GitHub (Jun 6, 2024):
Maybe related: https://github.com/actions/runner-images/issues/9995
@cpisto commented on GitHub (Jun 6, 2024):
Between 24.5.0 and 24.6.0 better-sqlite3 was upgraded from 9.1 to 9.6, between those versions better-sqlite3 was updated to support native arm builds on macOS, perhaps something broke there if the GitHub runner changed from x86 to arm between working and not working?
@youngcw commented on GitHub (Jun 6, 2024):
Maybe we need to setup the workflow to have two runners, one for arm one for x86.
@MatissJanis commented on GitHub (Jun 6, 2024):
That's not it. We narrowed it down to the github-runner being at fault here, not the dependency upgrade. See this comment.
@cpisto commented on GitHub (Jun 6, 2024):
Definitely strange. The dlopen error on psyber's debugtron seems to indicate the x86 binary is trying to dlopen an arm lib. I'm curious if an arm binary built on an arm runner would work.
@MatissJanis commented on GitHub (Jun 6, 2024):
I tried a few things here: https://github.com/actualbudget/actual/pull/2849
latestat this point)largeinstance (which theoretically should pick up arm64) - our open source license does not allow using large instancesOut of ideas at this point.
@cpisto commented on GitHub (Jun 6, 2024):
Maybe set the system architecture for the setup-node action to x86 or x64? It defaults to the runner architecture which is arm for -latest.
@MatissJanis commented on GitHub (Jun 7, 2024):
No bueno: https://github.com/actualbudget/actual/pull/2849
@cpisto commented on GitHub (Jun 7, 2024):
This is quite the rabbit hole. I'm wondering if the actions/cache is caching the node_modules from the previous arm node runtime. Something like this:
https://github.com/vitejs/vite-plugin-react/issues/425
@cpisto commented on GitHub (Jun 7, 2024):
It looks like it is- the cache key is only based on the os, not the architecture. So the now x86/x64 node runtime is using the cached node_modules for arm, which is likely where the "Bindings not found." error is coming from during the Electron build step.
@tdeebswihart commented on GitHub (Aug 3, 2024):
I'm encountering this on the most recently released version:
@Neosaurus commented on GitHub (Aug 4, 2024):
I'm experiencing this bug on the latest version also.
@ricky0829 commented on GitHub (Aug 8, 2024):
Same here, version: 24.8.0
M1 Macbook Pro.
Running in locally.
@Kidglove57 commented on GitHub (Aug 8, 2024):
This might just be the error I had on Silicon? Solved for me by enabling Rosetta for now.
@ricky0829 commented on GitHub (Aug 9, 2024):
Are you using the latest version too? If so, then maybe relative with chip type. I'm using M1Pro with Rosetta on. But why it need Rosetta? It's arm architecture.
@MikesGlitch commented on GitHub (Aug 10, 2024):
To keep this thread in the loop, I think it's fixed here:
https://github.com/actualbudget/actual/actions/runs/10322929844?pr=3220
For those with Arm CPU's, can you try out the latest build and tell me what you see?
I think some of you may see "this file is damaged" due to some Apple nonsense about notarizing the app (we plan on fixing that).
If you see the damaged file warning, I think running the below command will fix it:
Can someone confirm?
@TheRebootr commented on GitHub (Aug 11, 2024):
Hello @MikesGlitch ,
I just downloaded and installed the current Release today [v24.8.0].
I still have this error. However, as advised by @Kidglove57 above, I enabled Rosetta and that resolved the issue for now.
Machine:
Macbook Pro M3
@MikesGlitch commented on GitHub (Aug 11, 2024):
Thanks for checking. I think I fixed it here, can I get someone to try again?
https://github.com/actualbudget/actual/actions/runs/10339466938?pr=3220
Apologies for all this back and forward, I don't have a Arm64 mac so can't do it myself.
@MatissJanis commented on GitHub (Aug 11, 2024):
✅ This works on Intel if that helps (don't have an ARM machine).
@MikesGlitch commented on GitHub (Aug 12, 2024):
I have a PR up with the fix, thanks for the help everyone! 🚀
@MikesGlitch commented on GitHub (Aug 12, 2024):
Fixed by https://github.com/actualbudget/actual/pull/3220
@ricky0829 commented on GitHub (Aug 14, 2024):
It worked for me too! (M1Pro) Thanks!
@Neosaurus commented on GitHub (Aug 14, 2024):
Sadly still present for me :( Also M1 pro MBP 14"
@MikesGlitch commented on GitHub (Aug 14, 2024):
Can you confirm that you have the latest artefact and have run the command? If so, what error do you get?
@Kidglove57 commented on GitHub (Aug 14, 2024):
I'm testing the latest build on my M2 Mac. As expected I get the damaged file message. I tried running the command you mentioned. However Terminal is throwing an error:
zsh parse error near \n
@MikesGlitch commented on GitHub (Aug 14, 2024):
Are you running the command with the <> brackets? If you remove them it should work
A real life command might look similar to
@Neosaurus commented on GitHub (Aug 14, 2024):
The same as before, with an "unknown error opening x file". My server is running the latest version. I had to run the xattr command to get it to work
@MikesGlitch commented on GitHub (Aug 14, 2024):
This is odd because others have reported it working - and an arm64 should work the same no matter what machine its on.
Can you try removing it from your system, then re-downloading it from https://github.com/actualbudget/actual/releases/tag/v24.8.0 ?
If you still get the error can you open up devtools by clicking the "View" menu > "toggle devtools" > "Console" until you get the error and screen grab it for me?
@Kidglove57 commented on GitHub (Aug 14, 2024):
Still struggling a bit in terminal so?
xattr -c applications/actual.app
@MikesGlitch commented on GitHub (Aug 14, 2024):
For me it was:
@Kidglove57 commented on GitHub (Aug 14, 2024):
Thank you for persevering with me. I'm not sure what I was doing wrong - maybe incorrect spacing in the command. Anyhow, now working really well and I can confirm that export works too.
Just in case others are reading this - don't expect any response when you enter this command in terminal. But it does work
@Neosaurus commented on GitHub (Aug 15, 2024):
Here is the error:
I can confirm via Activity Monitor that this is the Apple Silicon release. The server runs on my x86 home server though, which could be the issue?
The previous release still works fine.
Edit: actually I see I'm using the intel release (unbeknownst to me) for the previous version - do I need to match the server architecture and my laptop architecture?
@MikesGlitch commented on GitHub (Aug 15, 2024):
Can we take this to Discord? Hard to have a convo on Github.
Here's the link to the support thread: https://discord.com/channels/937901803608096828/1271969489294200883
@ricky0829 commented on GitHub (Aug 18, 2024):
Hello @MikesGlitch, not sure if it related to this issue, but the export was error in macOS.
debug info:
@MikesGlitch commented on GitHub (Aug 18, 2024):
That error was unrelated, but it's fixed in the latest release as well (you'll have to download it again to get it).
We also have automatic backups in the Electron app - there's not much reason to do a manual export 👍