Priority/Impact
None
Description
Description
When adding a food item to the nutrition diary that has never been logged before by the user, the entry appears in the diary list but shows 0 kcal / 0g for all macros, and stays at 0 indefinitely (tested waiting 30+ minutes). The daily total is also not recalculated.
If the same ingredient is logged again afterward, or if a previously-used ingredient is logged, the values calculate correctly and instantly.
This appears to be a self-hosted Docker deployment issue, running PowerSync v1.24.0 (Unified Container, Open Edition) as introduced in wger 2.6.
Steps to reproduce
- Open the nutrition diary for today.
- Add an ingredient that has never been logged before in this account (e.g. a food never previously used).
- Observe: the entry appears in the diary with 0 kcal and 0g for all macros. The daily total does not include it.
- Wait several minutes (or hours) — the value never updates on its own.
- As a comparison, add an ingredient that was already logged before — this one calculates correctly immediately.
Server-side evidence (self-hosted, Docker, PowerSync backend)
Server logs confirm the write and the corresponding sync bucket are processed and delivered to the client successfully and quickly:
14:45:xx [NutritionRepository] Adding local diary entry for ingredient 1670 (client-side log)
14:46:02 Write checkpoint for user: 1 | ...
14:46:02 Updated checkpoint: 3919 | updated: ["1#user_ingredients|0[1670]", "1#user_activity|3[...]"]
14:46:02 checkpoint_complete: 3919 | operations_synced: 2
The user_ingredients bucket containing the new ingredient's nutritional data (id 1670) is created and pushed to the client, and the client acknowledges checkpoint_complete within seconds. I also verified directly in Postgres that the ingredient's nutrition_synced_ingredient row has correct macro values (energy, protein, carbohydrates, fat all populated correctly).
So the data is confirmed present and delivered to the client, but the UI never reflects it for that log entry.
What I've ruled out
- Not a network/reverse-proxy issue: confirmed sub-second round trip on writes (PUT to
/allauth/API) after fixing proxy_request_buffering off on both the internal nginx and the external reverse proxy.
- Not a replication issue: Postgres logical replication slot active, WAL replication confirmed working via server logs.
- Not missing ingredient data: verified directly via
SELECT in Postgres that the ingredient's macros are correctly populated in both nutrition_ingredient and nutrition_synced_ingredient.
- Not (only) a local DB corruption issue: fully wiped the app's local storage (Android "Clear storage") to force a complete fresh re-sync from scratch (confirmed via server logs: 3391 operations re-downloaded), and the bug still reproduces on a freshly synced, healthy local database.
Suspected cause
I noticed the sync stream reconnects very frequently (every few seconds to ~1-2 minutes) rather than staying open continuously, even during otherwise-idle periods:
"close_reason":"client closing stream"
My hypothesis is that this frequent reconnect cycle interrupts the client before it can properly apply/join the newly-received user_ingredients bucket data to the corresponding nutrition_logitem row, even though the checkpoint is acknowledged as complete. This would explain why already-known ingredients (already present in a previously-applied bucket) calculate instantly, while brand-new ones don't.
Environment
- Self-hosted via Docker (official
wger-project/docker repo, up to date as of August 2026)
- PowerSync service:
journeyapps/powersync-service:latest, v1.24.0, Unified Container, Open Edition
- Android app version: 2.0.4 (build 250)
powersync-dart-core: 2.3.3- Dart: 3.12.2
Workaround found
Fully clearing the app's local storage (Android Settings > Apps > wger > Storage > Clear storage) and letting it perform a full fresh re-sync temporarily fixes existing 0-value entries, but the bug reproduces again as soon as a genuinely new ingredient is logged. Not a viable long-term workaround.
Server version
No response
Mobile app version
No response
Priority/Impact
None
Description
Description
When adding a food item to the nutrition diary that has never been logged before by the user, the entry appears in the diary list but shows 0 kcal / 0g for all macros, and stays at 0 indefinitely (tested waiting 30+ minutes). The daily total is also not recalculated.
If the same ingredient is logged again afterward, or if a previously-used ingredient is logged, the values calculate correctly and instantly.
This appears to be a self-hosted Docker deployment issue, running PowerSync v1.24.0 (Unified Container, Open Edition) as introduced in wger 2.6.
Steps to reproduce
Server-side evidence (self-hosted, Docker, PowerSync backend)
Server logs confirm the write and the corresponding sync bucket are processed and delivered to the client successfully and quickly:
14:45:xx [NutritionRepository] Adding local diary entry for ingredient 1670 (client-side log)
14:46:02 Write checkpoint for user: 1 | ...
14:46:02 Updated checkpoint: 3919 | updated: ["1#user_ingredients|0[1670]", "1#user_activity|3[...]"]
14:46:02 checkpoint_complete: 3919 | operations_synced: 2
The
user_ingredientsbucket containing the new ingredient's nutritional data (id 1670) is created and pushed to the client, and the client acknowledgescheckpoint_completewithin seconds. I also verified directly in Postgres that the ingredient'snutrition_synced_ingredientrow has correct macro values (energy, protein, carbohydrates, fat all populated correctly).So the data is confirmed present and delivered to the client, but the UI never reflects it for that log entry.
What I've ruled out
/allauth/API) after fixingproxy_request_buffering offon both the internal nginx and the external reverse proxy.SELECTin Postgres that the ingredient's macros are correctly populated in bothnutrition_ingredientandnutrition_synced_ingredient.Suspected cause
I noticed the sync stream reconnects very frequently (every few seconds to ~1-2 minutes) rather than staying open continuously, even during otherwise-idle periods:
"close_reason":"client closing stream"
My hypothesis is that this frequent reconnect cycle interrupts the client before it can properly apply/join the newly-received
user_ingredientsbucket data to the correspondingnutrition_logitemrow, even though the checkpoint is acknowledged as complete. This would explain why already-known ingredients (already present in a previously-applied bucket) calculate instantly, while brand-new ones don't.Environment
wger-project/dockerrepo, up to date as of August 2026)journeyapps/powersync-service:latest, v1.24.0, Unified Container, Open Editionpowersync-dart-core: 2.3.3Workaround found
Fully clearing the app's local storage (Android Settings > Apps > wger > Storage > Clear storage) and letting it perform a full fresh re-sync temporarily fixes existing 0-value entries, but the bug reproduces again as soon as a genuinely new ingredient is logged. Not a viable long-term workaround.
Server version
No response
Mobile app version
No response