[BUG] - Items in shopping list not showing when added

[kabatp]

First Check

• This is not a feature request.
• I added a very descriptive title to this issue (title field is above this).
• I used the GitHub search to find a similar issue and didn't find it.
• I searched the Mealie documentation, with the integrated search.
• I already read the docs and didn't find an answer.
• This issue can be replicated on the demo site (https://demo.mealie.io/).

What is the issue you are experiencing?

When adding items to a shopping list, the items show up only for a brief moment before disappearing.

Steps to Reproduce

1. Create a new shopping list
2. Push Add button
3. Fill Note and Qty
4. Push Save button

Please provide relevant logs

Postgres:
2024-09-30 15:22:47.676156+02:002024-09-30T15:22:47.676156286+02:00
2024-09-30 15:22:47.676202+02:00PostgreSQL Database directory appears to contain a database; Skipping initialization
2024-09-30 15:22:47.676213+02:002024-09-30T15:22:47.676213243+02:00
2024-09-30 15:22:47.910056+02:002024-09-30 15:22:47.910 CEST [1] LOG: starting PostgreSQL 15.2 (Debian 15.2-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
2024-09-30 15:22:47.910178+02:002024-09-30 15:22:47.910 CEST [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
2024-09-30 15:22:47.910203+02:002024-09-30 15:22:47.910 CEST [1] LOG: listening on IPv6 address "::", port 5432
2024-09-30 15:22:47.924104+02:002024-09-30 15:22:47.924 CEST [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2024-09-30 15:22:47.976648+02:002024-09-30 15:22:47.976 CEST [16] LOG: database system was shut down at 2024-09-30 15:22:28 CEST
2024-09-30 15:22:48.045568+02:002024-09-30 15:22:48.045 CEST [1] LOG: database system is ready to accept connections
2024-09-30 15:27:48.063082+02:002024-09-30 15:27:48.063 CEST [14] LOG: checkpoint starting: time
2024-09-30 15:27:49.422676+02:002024-09-30 15:27:49.422 CEST [14] LOG: checkpoint complete: wrote 14 buffers (0.1%); 0 WAL file(s) added, 0 removed, 0 recycled; write=1.203 s, sync=0.146 s, total=1.360 s; sync files=15, longest=0.040 s, average=0.010 s; distance=23 kB, estimate=23 kB
2024-09-30 15:32:48.460421+02:002024-09-30 15:32:48.460 CEST [14] LOG: checkpoint starting: time
2024-09-30 15:32:50.795922+02:002024-09-30 15:32:50.795 CEST [14] LOG: checkpoint complete: wrote 24 buffers (0.1%); 0 WAL file(s) added, 0 removed, 0 recycled; write=2.305 s, sync=0.021 s, total=2.336 s; sync files=20, longest=0.012 s, average=0.002 s; distance=76 kB, estimate=76 kB

Mealie:
2024-09-30 15:22:47.676156+02:002024-09-30T15:22:47.676156286+02:00
2024-09-30 15:22:47.676202+02:00PostgreSQL Database directory appears to contain a database; Skipping initialization
2024-09-30 15:22:47.676213+02:002024-09-30T15:22:47.676213243+02:00
2024-09-30 15:22:47.910056+02:002024-09-30 15:22:47.910 CEST [1] LOG: starting PostgreSQL 15.2 (Debian 15.2-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
2024-09-30 15:22:47.910178+02:002024-09-30 15:22:47.910 CEST [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
2024-09-30 15:22:47.910203+02:002024-09-30 15:22:47.910 CEST [1] LOG: listening on IPv6 address "::", port 5432
2024-09-30 15:22:47.924104+02:002024-09-30 15:22:47.924 CEST [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2024-09-30 15:22:47.976648+02:002024-09-30 15:22:47.976 CEST [16] LOG: database system was shut down at 2024-09-30 15:22:28 CEST
2024-09-30 15:22:48.045568+02:002024-09-30 15:22:48.045 CEST [1] LOG: database system is ready to accept connections
2024-09-30 15:27:48.063082+02:002024-09-30 15:27:48.063 CEST [14] LOG: checkpoint starting: time
2024-09-30 15:27:49.422676+02:002024-09-30 15:27:49.422 CEST [14] LOG: checkpoint complete: wrote 14 buffers (0.1%); 0 WAL file(s) added, 0 removed, 0 recycled; write=1.203 s, sync=0.146 s, total=1.360 s; sync files=15, longest=0.040 s, average=0.010 s; distance=23 kB, estimate=23 kB
2024-09-30 15:32:48.460421+02:002024-09-30 15:32:48.460 CEST [14] LOG: checkpoint starting: time
2024-09-30 15:32:50.795922+02:002024-09-30 15:32:50.795 CEST [14] LOG: checkpoint complete: wrote 24 buffers (0.1%); 0 WAL file(s) added, 0 removed, 0 recycled; write=2.305 s, sync=0.021 s, total=2.336 s; sync files=20, longest=0.012 s, average=0.002 s; distance=76 kB, estimate=76 kB

Mealie Version

App Version: 1.12.0
Chart Version: 1.0.25

Deployment

TrueNAS

Additional Deployment Details

TrueNas Scale: Dragonfish-24.04.2.2

[michael-genson]

Can you share your docker compose? Unsure if TrueNAS has that. If not, what timezone is your server in?

[kabatp]

Can you share your docker compose? Unsure if TrueNAS has that. If not, what timezone is your server in?

Timezone: 'Europe/Bratislava' timezone

Docker compose is not installed in APPS pods by default

[kabatp]

Mealie app settings:

[michael-genson]

I tried reproducing this locally with a db and client in that timezone and couldn't. Can you try switching your timezone to UTC and seeing if that fixes the problem?

[kabatp]

I tried reproducing this locally with a db and client in that timezone and couldn't. Can you try switching your timezone to UTC and seeing if that fixes the problem?

Changing the timezone to UTC did not help to resolve the issue

[michael-genson]

Are you getting any server errors? Are you getting any client errors (e.g. F12 console in Chrome)?

[kabatp]

Are you getting any server errors? Are you getting any client errors (e.g. F12 console in Chrome)?

Console response when I push the add button:

There are no errors on the server side as far as I can check - the pods logs were attached in the post

[michael-genson]

Can you share the response from the network request that contains the shopping list when you load the page? (should be sent to .../api/groups/shopping/lists/{yourListId}). I'm trying to see why your client is behind your shopping list

Also, are you able to query your db directly and see what the "created_at" and "update_at" values of your shopping list are? Wondering if they're getting stored in a weird way

[kabatp]

Network response after pushing the Add button:

When I opened the shopping list today, I found one checked item, and 1st item I added today was successfully added (the rest wasn't).

The response for the GET in 1st pic:

I can't give you pgsql results as pgAdmin on TrueNAS has some package chmod issue and cannot be deployed, but the created at and updated at are visible in GET response

[michael-genson]

It looks like something is up with your server time. Can you check the current time on your machine and make sure it's correct?

Your timestamp of 2024-10-02T16:12:52.346148Z is wrong (it's currently 15:09 UTC), it's an hour and several minutes ahead. If it had been exactly one or two hours I would think it's likely something wrong with Mealie, but an hour and several minutes is suspicious.

[kabatp]

This is TrueNAS time

I tried to change the mealie timezone back to EUROPE/Bratislava, and in that case, the response is:

I would assume that the one hour would be the summer/winter time in Europe, but the minutes I am not able to justify

[michael-genson]

Okay so somehow the timestamp is changing even though it's purportedly returning UTC time. Unfortunately I'll need to see how it's being stored in the database to diagnose what's going on there. Since the API is returning a time and calling it UTC, but it's not UTC, it's almost certainly reading something weird from the db.

The minutes being wrong is... weird, since your server time is correct.

[kabatp]

Hey, I managed to get into the DB, what exactly do you need to see?

[michael-genson]

If you could create a new shopping list, note the current time in UTC, then provide the created_at and update_at values from the database from that list. Hopefully that sheds some light on the issue.

[kabatp]

The mealie instance is set up as follows

And I created new list:

The minutes are OK, but seems like the time is from TrueNAS Scale and not from the app settings

[kabatp]

Created new one with UTC+2 setup and got following

[michael-genson]

Okay so it's definitely being stored wrong in the database then, and it has no timezone. Let me look into this.

Side note, when you change the timezone in Mealie, are you rebuilding the container? Just changing the value won't have an effect on the instance.

[kabatp]

A container is not rebuilt in the process of settings update in TrueNAS Scale, but it is restarted. The settings changes should take place after the restart of the container.

[michael-genson]

I'm not familiar with TrueNAS, but restarting a docker container doesn't change environment variables, you have to rebuild the container

[kabatp]

Timezone is not part of environment variables but direct settings in TrueNAS, even changing env variables in TrueNAS and restarting the container is enough to make a change.

[michael-genson]

Are you not setting the TZ environment variable? Is TrueNAS using something else?
https://docs.mealie.io/documentation/getting-started/installation/backend-config/#general

Can you try setting the TrueNAS timezone, and the TZ environment variable, and then rebuild the container?

[kabatp]

No, there is a direct setting for Timezone in the App setup

Any other insert into the DB works - recipes, meal planners, cookbooks, organizers...

I tried to insert an item in the shopping list directly via DB and then the Item is shown in the Shopping List, but I cannot manipulate it in any way, not even check, or rename it

[michael-genson]

It looks like this is setting the timezone. Try setting this to UTC.

Just for good measure, also add the TZ env var with the value UTC.

Then rebuild the container and see what happens.

[kabatp]

I already tried changing the Timezone setting when creating UTC shopping list. This time I set up env variable to UTC and timezone to UTC, got this

[kabatp]

I changed the timezone of my TrueNAS Scale system and got the same results

Apparently none of these are taking the changes - I will try with a new instance of mealie set up with UTC timezone from scratch

[michael-genson]

Okay I was finally able to reproduce this. Looks like manually setting the postgres timezone to Europe/Bratislava and leaving Mealie as UTC triggers the issue. This confirms there's an issue going between the Python layer and the db layer.

I would guess that your idea of recreating the whole instance as UTC will fix it since it will (probably?) set postgres to UTC. Otherwise you can try manually switching it to UTC:

SET timezone TO 'UTC'

[michael-genson]

#4310 should fix this, but in the meantime the above should resolve it for you. I'll keep this one open until you're able to confirm it's resolved.

[kabatp]

Setting the DB timezone to UTC worked well, but I had to restart the container to reflect the changes.

I also installed a new instance to test it out. Yes, setting the timezone during installation to UTC worked well.

Thank you!

[michael-genson]

Great to hear! I'll keep this open until #4310 is merged