Mobile app shows "User profile is unavailable" although profile exists and API returns valid data

[hardwareadictos]

Priority/Impact

Medium (affects some functionality)

Description

Environment

• Wger Server: 2.6
• Deployment: Official Docker deployment from wger-project/docker
• PostgreSQL 15
• PowerSync enabled
• Android App: 2.0.0 (build 210)

Problem

The Android app successfully authenticates and PowerSync synchronization appears to work correctly, but the profile section of the app displays:

User profile is unavailable

Some profile-related screens also remain loading indefinitely.

What works

• Login works correctly.
• PowerSync starts and synchronizes successfully.
• The user profile exists in the database.
• The web interface works correctly.
• The REST API returns the expected profile data.
• No backend errors appear in Django logs.
• No PowerSync errors appear in PowerSync logs.

API Response

Request:

GET /api/v2/userprofile/

Response:

{
  "username": "TestUser",
  "email": "user@example.invalid",
  "email_verified": true,
  "is_trustworthy": true,
  "date_joined": "2026-01-15T10:30:00+00:00",
  "gym": null,
  "weight_rounding": null,
  "repetitions_rounding": null,
  "is_temporary": false,
  "workout_reminder_active": false,
  "workout_reminder": 14,
  "workout_duration": 12,
  "last_workout_notification": null,
  "notification_language": 4,
  "age": 35,
  "birthdate": "1990-01-01",
  "height": 180,
  "gender": "1",
  "sleep_hours": 7,
  "work_hours": 8,
  "work_intensity": "1",
  "sport_hours": 4,
  "sport_intensity": "2",
  "freetime_hours": 6,
  "freetime_intensity": "1",
  "calories": 2500,
  "weight_unit": "kg",
  "num_days_weight_reminder": 0
}

The actual values have been anonymized, but the structure and data types match the real API response returned by the server.

PowerSync

PowerSync starts successfully and syncs the user profile bucket:

user_profile["2"]
status=200
operations_synced=2

The synchronization completes successfully and checkpoints advance normally.

Troubleshooting already performed

• Verified PowerSync configuration.
• Verified PowerSync token generation.
• Verified PowerSync synchronization.
• Verified user profile exists in PostgreSQL.
• Verified profile contains valid values (height, birthdate, gender, etc.).
• Verified REST API returns profile data correctly.
• Cleared application data.
• Logged out and logged in again.
• No Django exceptions or tracebacks found.
• No PowerSync errors found.

Expected behavior

The mobile app should display the user profile and allow access to profile-related screens.

Actual behavior

The mobile app displays:

User profile is unavailable

even though the profile exists and the API returns valid data.

Sync status in a perpetual Connecting state.

My profile in a loading ring loop.

Additional observation

While reviewing the logs, I could see the app successfully calling endpoints such as:

/api/v2/version/
/api/v2/powersync-token/
/api/v2/trophy/
/api/v2/user-trophy/

and all of them return HTTP 200.

However, I could not find any corresponding backend errors explaining why the profile screen fails to load.

Server version

2.6 -> Docker, latest tag

Mobile app version

2.0.0

[rolandgeider]

Hi! Thanks for reporting this. Actually somebody else also mentioned that "profile is unavailable" but it disappeared for them some time later. I thought it was just some slow network access, but if you get that as well it's probably something else, I'll look into it

also, you probably mean version 2.6 :)

[hardwareadictos]

Hi! Thanks for reporting this. Actually somebody else also mentioned that "profile is unavailable" but it disappeared for them some time later. I thought it was just some slow network access, but if you get that as well it's probably something else, I'll look into it

also, you probably mean version 2.6 :)

You are absolutelly right! 2.6 server, corrected it on the issue.

On my case i don't have a slow connection, 2.5G bandwidth VPS , two days with the service deployed, by accessing on the web browser i don't have this issue.

[rolandgeider]

The problem is probably that powersync can't properly reach your server. Can you check that the powersync url that /api/v2/powersync-token returns is correct? I also had a problem with anubis sometimes intercepting requests there, you might have something similar in front?

[hardwareadictos]

The problem is probably that powersync can't properly reach your server. Can you check that the powersync url that /api/v2/powersync-token returns is correct? I also had a problem with anubis sometimes intercepting requests there, you might have something similar in front?

I checked the URL returned by /api/v2/powersync-token.

The API returns:

{
  "powersync_url": "https://xxxxx.xxxxx.net/ps/"
}

I also verified that the URL is reachable from outside the network:

curl -v https://xxxxx.xxxxx.net/ps/

The request reaches PowerSync successfully and returns:

{
  "error": {
    "code": "PSYNC_S2002",
    "status": 404,
    "description": "The path does not exist on this server",
    "details": "The path GET \"/\" does not exist on this server"
  }
}

which appears to be a normal PowerSync response for a GET request against /.

I am not using Anubis or any anti-bot protection. The service is behind nginx only.

PowerSync logs also show successful synchronization and HTTP 200 responses for /ps/sync/stream.

[florent4014]

I get the exact same behavior. And i just updated the mobile app to v2.0.1, but the issue is still there.

[rolandgeider]

yes that's the regular powersync response if you GET the root. So that seems to be working fine.

Just to be sure, can you check if you have in the nginx config proxy_buffering off; for the powersync /ps/ path?

[Ricardo544]

Hi,
I'm hitting something that might be related, also on a fresh self-hosted Docker deployment (server 2.6, PowerSync enabled, app 2.0.1 build 220).
Before things go wrong, I also see a profile/loading state similar to what's described here. But in my case it escalates much further: the app then gets stuck in a repeated ANR loop ("App isn't responding — Close app / Wait") roughly every 10 seconds, and tapping "Wait" never resolves it — it just keeps coming back. Eventually, this puts enough memory pressure on the device that other apps running in the background get killed one after another by the OS (in my case: Tasker, MacroDroid, and a couple of messaging/home-automation apps). It's not just the wger app freezing, it affects the whole phone.
Server-side, the PowerSync logs show the initial core stream sync (exercises/images/videos reference data — about 872 exercises with images and videos in my case) taking 115 seconds and being flagged by PowerSync itself as an oversized bucket:
"large_buckets":{"1#core|0[]":12794}
"operations_synced":12842
"stream_ms":114903
I wonder if this could be a shared root cause — a long-running initial core sync that blocks the UI thread for too long, manifesting as "profile unavailable" in some cases and as a full ANR loop with background app kills in others (possibly depending on device load at the time).
Environment: Samsung Galaxy S22 Ultra, Android, self-hosted Docker (wger 2.6), full exercise catalog + images + videos synced server-side before first app login.
Happy to provide more logs or test a fix if needed. Thanks for looking into this!

[Ricardo544]

Yes, confirmed — proxy_buffering off; is already present in the /ps/ location block, it's part of the default config shipped with the official wger Docker image:
location /ps/ {
proxy_pass http://powersync/;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $final_forwarded_proto;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_buffering off;
proxy_read_timeout 1d;
proxy_send_timeout 1d;
}
I haven't customized this part of the nginx config, so this is the stock setup from the docker repo. I do have an additional HAProxy layer in front of nginx for TLS termination (port 5693), but that shouldn't buffer either since it's just a plain TCP/HTTP passthrough to nginx on port 80.

[rolandgeider]

thanks for those numbers @Ricardo544 . The "profile unavailable" is expected in this context, we read the profile to display the units, so till we have all the data, we will see the warning. Was this the first sync right after deploying? Powersync needs to create all the buckets first, and I'm not sure what would happen if you connected a client while this process is running.

Can you run

docker compose exec db psql -U wger -d wger -c \
"SELECT slot_name, active, wal_status,
        pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained_wal
 FROM pg_replication_slots;"

A slot with active = f or a large amount of retained WAL would point at a replication problem (but I don't really expect one).

Edit: did the data actually get synced to the phone after a while at all?

[Ricardo544]

Thanks for the clarification on "profile unavailable" — that explains that part.
To answer your questions:
Was this the first sync right after deploying?

Yes, exactly — this was the very first sync, just a few hours after the initial deployment, right after I had bulk-synced the full catalog server-side (exercise translations/images/videos, ~3M ingredients via sync-ingredients-bulk, and exercise videos via download-exercise-videos). So the client connected for the first time right into a freshly fully-populated core bucket.
Did the data actually get synced to the phone after a while at all?

Yes — the sync did complete successfully. Server-side log for that session:
"message":"Sync stream complete"
"operations_synced":12842
"stream_ms":114903
status: 200
And immediately after, normal API calls (/api/v2/trophy/progress/, /api/v2/routine/, etc.) returned fine and fast. So the data did arrive — the issue seems to be specifically the ~115s window during which the app's UI thread gets blocked/ANR'd while that large core bucket is being processed, not a failure to sync.
Replication slot status, as requested:
slot_name | active | wal_status | retained_wal
------------------+--------+------------+--------------
powersync_1_ed34 | t | reserved | 15 kB
Looks healthy — active, no retained WAL buildup. So no replication issue on my end as far as I can tell.
Happy to test anything else that would help narrow this down.

[rolandgeider]

alright, thanks. So it does indeed look more like the initial sync is completely blocking the phone, which I'm still wondering why it did cause so many problems for you, I have a pixel 7 which is similar and didn't have any problems at all (I think for me it barely took more than half a minute?). In any case this is a good datapoint and I've added a small debounce that should cushion some of the work done on the very first sync

[Ricardo544]

That's great to hear, thanks for digging into it and pushing a fix already!
Quick question on deployment: is this debounce fix already live in the current Docker image (e.g. the latest tag), or is it merged but pending an actual release/tag? If it's not in a published image yet, is there a way for me to pull a dev/edge build to test it, or should I just wait for the next tagged release and do a regular docker compose pull && docker compose up -d?
Happy to confirm once I've tested it on my end either way.

[rolandgeider]

the debounce is for the mobile app, which is not released yet (but you can also build it yourself if you want). Also this is a bit of guesswork since I never had any problems with the initial sync: what we do now is debounce some of the more problematic rebuilds that were happening pretty often the first time the whole data stream arrived. After that this is largely irrelevant as you only sync a handful of entries at a time.

But in general: for the backend we build the docker image on every push, so you can just use latest and get the newer features as soon as they land (these are also always compatible, breaking changes only occur when we release)