github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-03-09 11:42:54 -05:00
Code Issues 250 Packages Projects Releases 53 Wiki Activity

[Bug]: iOS/Safari client loses connection to server and it cannot be restored without removing all the local website data #2951

New Issue
Open
opened 2026-02-28 20:33:14 -06:00 by GiteaMirror · 4 comments
GiteaMirror commented 2026-02-28 20:33:14 -06:00
Owner
Copy Link

Originally created by @retifrav on GitHub (Feb 19, 2026).

What happened?

I have Actual instance open in a Safari tab, and sometimes I work with it offline (no internet connection). When I get back online, usually the data syncs just fine, which is super convenient (basically, eliminates a need to have a proper application for it). However, sometimes the client (that Safari) "loses" the server, so it looks like this in settings (N/A for server version):

Image

Trying to reload the page (when I am online) or/and restarting Safari does not resolve this, server is still offline and N/A. Trying to re-enter the same URL by clicking on Change server URL menu item fails with this error:

Server is not running at this URL

here's also a screenshot:

Image

But server is most definitely running at this URL, because it was working before and it is still working in other browsers on my other devices at this exact same URL.

Only when I go to iOS settings and remove all website data for this host in Safari (and restart Safari), then I get the client working and connected to the server again (with absolutely the same URL that was failing earlier on that screenshot above).

Not sure if this is specific to iOS/Safari, but so far I noticed this problem only happening there.

It is also probably worth to mention that I use a self-signed certificate on the server, so I need to trust it on the initial page load in Safari. But then again, if that was a problem for the Actual frontend, it would have failed to connect to that server already on the initial load.

The Actual version is v26.2.0.

How can we reproduce the issue?

  1. Open Actual instance in Safari on iOS;
  2. Disconnect from the internet;
  3. Make some changes;
    • or maybe just stay offline for some (unknown period of) time;
  4. Get back online;
  5. The server will be offline and server version will be N/A.

Unfortunately, these steps do not always reproduce the problem, I noticed it happening only once in a week or so.

Where are you hosting Actual?

Docker

What browsers are you seeing the problem on?

Safari

Operating System

Mobile Device

Originally created by @retifrav on GitHub (Feb 19, 2026). ### What happened? I have Actual instance open in a Safari tab, and sometimes I work with it offline (*no internet connection*). When I get back online, usually the data syncs just fine, which is super convenient (*basically, eliminates a need to have a proper application for it*). However, sometimes the client (*that Safari*) "loses" the server, so it looks like this in settings (*`N/A` for server version*): <img width="780" height="229" alt="Image" src="https://github.com/user-attachments/assets/4ee5ae78-0181-4672-9f36-ad2d964095ff" /> Trying to reload the page (*when I am online*) or/and restarting Safari does not resolve this, server is still offline and `N/A`. Trying to re-enter the same URL by clicking on `Change server URL` menu item fails with this error: ``` Server is not running at this URL ``` here's also a screenshot: <img width="555" height="355" alt="Image" src="https://github.com/user-attachments/assets/c9182b48-9598-44ad-b693-e1910e7a56ed" /> But server is most definitely running at this URL, because it was working before and it is still working in other browsers on my other devices at this exact same URL. Only when I go to iOS settings and remove all website data for this host in Safari (*and restart Safari*), then I get the client working and connected to the server again (*with absolutely the same URL that was failing earlier on that screenshot above*). Not sure if this is specific to iOS/Safari, but so far I noticed this problem only happening there. It is also probably worth to mention that I use a self-signed certificate on the server, so I need to trust it on the initial page load in Safari. But then again, if that was a problem for the Actual frontend, it would have failed to connect to that server already on the initial load. The Actual version is `v26.2.0`. ### How can we reproduce the issue? 1. Open Actual instance in Safari on iOS; 2. Disconnect from the internet; 3. Make some changes; - or maybe just stay offline for some (*unknown period of*) time; 5. Get back online; 6. The server will be offline and server version will be `N/A`. Unfortunately, these steps do not always reproduce the problem, I noticed it happening only once in a week or so. ### Where are you hosting Actual? Docker ### What browsers are you seeing the problem on? Safari ### Operating System Mobile Device
GiteaMirror added the can’t replicateresponsivebugserver labels 2026-02-28 20:33:14 -06:00
GiteaMirror commented 2026-02-28 20:33:14 -06:00
Author
Owner
Copy Link

@MatissJanis commented on GitHub (Feb 23, 2026):

👋 I'll venture a guess that you have some sort of auth mechanism in front of Actual? Authelia or something something similar?

@MatissJanis commented on GitHub (Feb 23, 2026): 👋 I'll venture a guess that you have some sort of auth mechanism in front of Actual? Authelia or something something similar?
GiteaMirror commented 2026-02-28 20:33:15 -06:00
Author
Owner
Copy Link

@retifrav commented on GitHub (Feb 24, 2026):

Well, it does load a "Sign in" page in a fresh/private browser:

Image

and after that it shows a "Decrypt" dialog on selecting a budget file:

Image

but both of these are default pages of the Actual, and I figured that adding my own authentication in front of those would be redundant, so I have not added any.

I do have NGINX in front of it, but like I said it does not introduce any additional authentication, it is only used as a reverse-proxy. If anything, the NGINX config is this:

map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}

server {
    listen 11013;

    location / {
        # `actual` in the URL below is the Docker container name where Actual runs
        proxy_pass http://actual:5006/;
        proxy_http_version 1.1;
        proxy_set_header Host $host:$server_port;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $http_host;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
    }
}

...he-he, I forgot to mention that in front of that NGINX there is also Synology's own NGINX (I am running all that on a Synology NAS), which adds HTTPS into the mix (with a self-signed certificate, as I mentioned), but that one does not add any authentication either.

Looking at that setup of mine, I'd say I should probably try running a testing instance on a regular web-server with a proper certificate and maybe with no reverse-proxy at all - just to reduce the amount of moving parts. So if you'd like me to try to reproduce the problem in that cleaner/minimal environment, I can do so.

@retifrav commented on GitHub (Feb 24, 2026): Well, it does load a "Sign in" page in a fresh/private browser: <img width="678" height="329" alt="Image" src="https://github.com/user-attachments/assets/720a479c-e807-4edd-af51-a70db1af7f9b" /> and after that it shows a "Decrypt" dialog on selecting a budget file: <img width="770" height="502" alt="Image" src="https://github.com/user-attachments/assets/813f002c-255e-49cd-941e-082fa78412ea" /> but both of these are default pages of the Actual, and I figured that adding my own authentication in front of those would be redundant, so I have not added any. I do have NGINX in front of it, but like I said it does not introduce any additional authentication, it is only used as a reverse-proxy. If anything, the NGINX config is this: ``` nginx map $http_upgrade $connection_upgrade { default upgrade; '' close; } server { listen 11013; location / { # `actual` in the URL below is the Docker container name where Actual runs proxy_pass http://actual:5006/; proxy_http_version 1.1; proxy_set_header Host $host:$server_port; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Host $http_host; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; } } ``` ...he-he, I forgot to mention that in front of that NGINX there is also Synology's own NGINX (*I am running all that on a [Synology NAS](https://www.synology.com/en-global/dsm)*), which adds HTTPS into the mix (*with a self-signed certificate, as I mentioned*), but that one does not add any authentication either. Looking at that setup of mine, I'd say I should probably try running a testing instance on a regular web-server with a proper certificate and maybe with no reverse-proxy at all - just to reduce the amount of moving parts. So if you'd like me to try to reproduce the problem in that cleaner/minimal environment, I can do so.
GiteaMirror commented 2026-02-28 20:33:15 -06:00
Author
Owner
Copy Link

@MatissJanis commented on GitHub (Feb 25, 2026):

What I think is happening is: after a while the session to Synology/nginx (apologies, I am not an expert in either of these technologies) lapses. Thus the next time actual tries to hit the "/sync" endpoint - it gets back a 401/403 from the middleware (it is unable to reach the AB server). Thus - you get a "AB is not configured on this server" error because we do not recognise the response we get back.

It would be good if you could confirm this. The next time you get the "AB is not configured.." error - open up the network tab in devtools and look for the failing API call. It would be very interesting to know the status code and response of that request.

Additionally: maybe there is something interesting in console logs as well at that stage.

@MatissJanis commented on GitHub (Feb 25, 2026): What I think is happening is: after a while the session to Synology/nginx (apologies, I am not an expert in either of these technologies) lapses. Thus the next time actual tries to hit the "/sync" endpoint - it gets back a 401/403 from the middleware (it is unable to reach the AB server). Thus - you get a "AB is not configured on this server" error because we do not recognise the response we get back. It would be good if you could confirm this. The next time you get the "AB is not configured.." error - open up the network tab in devtools and look for the failing API call. It would be very interesting to know the status code and response of that request. Additionally: maybe there is something interesting in console logs as well at that stage.
GiteaMirror commented 2026-02-28 20:33:15 -06:00
Author
Owner
Copy Link

@retifrav commented on GitHub (Feb 25, 2026):

First, I think I've managed to more or less reliably reproduce the issue, here are the updated steps:

  1. Open Actual instance in Safari on iOS;
  2. Go offline, disconnect from the internet;
  3. Make some changes, such as add a single simple transaction;
  4. While still being offline, open the Settings page, and in there the server version label value should change to N/A;
    • if it hasn't changed, reload the page (even though you are offline), then it should change;
  5. Get back online, connect to the internet;
  6. Try to reload the page, but it will never re-gain connection to the server.

Next, as you said, I tried to inspect the network requests. Getting web-inspector to work on iOS was a bit of a struggle, but I finally got it. However, there was not a single error message with the text not configured on this server in the console (but there were others, see below). On the network tab there were several failed requests, including those to /sync endpoint:

Image

but none of the failed requests had a status code, so it looks like they were never actually sent:

Image

And console contained some hints:

[Log] Syncing since – "2026-02-23T07:06:46.151Z-0000-a242b18b9a4f94d5" – 15 – "(attempt: 0)" (kcab.worker.DE5uAdQe.js, line 1)
[Error] Failed to load resource: The certificate for this server is invalid.
[Log] Error: PostError: network-failure (kcab.worker.DE5uAdQe.js, line 1)

So it looks like the self-signed certificate is an issue after all? Even though, like I said in the original post, in that case I'd expect it to fail already on the initial load and never work at all, however what happens is that it only causes troubles when coming back online from being offline. I really hope this is not some Safari bug, because in that case you likely won't be able to do anything about it.

@retifrav commented on GitHub (Feb 25, 2026): First, I think I've managed to more or less reliably reproduce the issue, here are the updated steps: 1. Open Actual instance in Safari on iOS; 2. Go offline, disconnect from the internet; 3. Make some changes, such as add a single simple transaction; 4. While still being offline, open the Settings page, and in there the server version label value should change to `N/A`; - if it hasn't changed, reload the page (*even though you are offline*), then it should change; 5. Get back online, connect to the internet; 6. Try to reload the page, but it will never re-gain connection to the server. Next, as you said, I tried to inspect the network requests. Getting web-inspector to work on iOS was a bit of a struggle, but I finally got it. However, there was not a single error message with the text `not configured on this server` in the console (*but there were others, see below*). On the network tab there were several failed requests, including those to `/sync` endpoint: <img width="501" height="425" alt="Image" src="https://github.com/user-attachments/assets/38f2c3df-4067-43e3-8e26-2dcb60feb84a" /> but none of the failed requests had a status code, so it looks like they were never actually sent: <img width="854" height="445" alt="Image" src="https://github.com/user-attachments/assets/39b8991d-42ee-488d-8b85-981bd9169116" /> And console contained some hints: ``` [Log] Syncing since – "2026-02-23T07:06:46.151Z-0000-a242b18b9a4f94d5" – 15 – "(attempt: 0)" (kcab.worker.DE5uAdQe.js, line 1) [Error] Failed to load resource: The certificate for this server is invalid. [Log] Error: PostError: network-failure (kcab.worker.DE5uAdQe.js, line 1) ``` So it looks like the self-signed certificate is an issue after all? Even though, like I said in the original post, in that case I'd expect it to fail already on the initial load and never work at all, however what happens is that it only causes troubles when coming back online from being offline. I really hope this is not some Safari bug, because in that case you likely won't be able to do anything about it.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
AI generated
API
bank sync
budgeting
bug
can’t replicate
dependencies
docker
documentation
electron
experimental feature
feature
feedback
goal templates
good first issue
help wanted
importers
maintenance
needs info
needs testing
needs triage
needs votes
openid
payees
pull-request
Mirrored from GitHub Pull Request
 regression
reports
responsive
rules
schedules
server
✨ merged
split transactions
tech debt
theme
transaction import
transaction reconciliation
transactions
translations
upstream
user interface
✅ approved
wontfix
No Label bug can’t replicate responsive server
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#2951
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?