Error after updating to 2.10.1

[DenuxPlays]

Describe the bug
Updated from 2.10.0 to 2.10.1 and got the following error:

Everything worked fine before.

The thing I did was:

docker compose down -v
docker compose pull
docker compose up -d

Used docker compose with the following file:

version: "3.8"
services:
  wakapi:
    image: ghcr.io/muety/wakapi:latest
    restart: unless-stopped
    container_name: wakapi
    ports:
      - "127.0.0.1:7523:3000"
    volumes:
      - ./data:/data
    environment:
      WAKAPI_PASSWORD_SALT: ${WAKAPI_PASSWORD_SALT}
      WAKAPI_PUBLIC_URL: ${WAKAPI_PUBLIC_URL}
      WAKAPI_DB_HOST: db
      WAKAPI_DB_PORT: 3306
      WAKAPI_DB_USER: ${DATABASE_USERNAME}
      WAKAPI_DB_PASSWORD: ${DATABASE_PASSWORD}
      WAKAPI_DB_NAME: ${DATABASE_NAME}
      WAKAPI_DB_TYPE: mysql
    depends_on:
      db:
        condition: service_healthy

  db:
    image: mariadb:latest
    restart: unless-stopped
    volumes:
      - ./db:/var/lib/mysql
    environment:
      MYSQL_ROOT_PASSWORD: ${DATABASE_ROOT_PASSWORD}
      MYSQL_USER: ${DATABASE_USERNAME}
      MYSQL_PASSWORD: ${DATABASE_PASSWORD}
      MYSQL_DATABASE: ${DATABASE_NAME}
      TZ: ${TZ}
    healthcheck:
      test: [ 'CMD', '/usr/local/bin/healthcheck.sh', '--innodb_initialized' ]
      timeout: 5s
      interval: 5s
      retries: 5

[DenuxPlays]

After updating the tag to 2.10.0 everything works fine.

[DenuxPlays]

I can reproduce it with a clean install.
Host is running Fedora 39 (both on my server where the error occurred the first time and on my laptop)

[Totto16]

Same here, 2.10.0 works, 2.10.1 not 😓

[eli-yip]

Same problem, 2.10.0 works fine.

[bboysoulcn]

same

[YC]

This seems like an issue from upgrading configor.

listen_ipv4: 127.0.0.1              # leave blank to disable ipv4
listen_ipv6:                     # leave blank to disable ipv6

1.2.1:

2023-12-29T16:13:56.82323559+11:00 [INFO ] 👉 Listening for HTTP on 127.0.0.1:3000... ✅

The value of listen_ipv6 is blank.

1.2.2:

2023-12-29T16:12:56.344460922+11:00 [INFO ] 👉 Listening for HTTP on 127.0.0.1:3000... ✅
2023-12-29T16:12:56.344470121+11:00 [INFO ] 👉 Listening for HTTP on [::1]:3000... ✅

The value of listen_ipv6 is ::1.

[xMdb]

CR using Docker :latest tag (2.10.1)

[muety]

Waking up to 13 unread e-mails from a GitHub issue is a great start into the day! 😄 First of all, please apologize these inconveniences! Should have tested in Docker before releasing... Also, thanks a lot to @YC for reacting so promptly!

I took a look at this issue and here's a short summary:

• configor upgraded its dependency of yaml to v3 (already 11 months ago, but apparently they put a new tag only now)
• Either related to that version upgrade or due to a change in the library itself, empty YAML values won't override default values anymore (not even when omitempty flag is set), which is somewhat confusing behavior imo.
• Because Docker doesn't have IPv6, we disable listening on a v6 interface during the build process, by setting listen_ipv6 to an empty string see here, while the default is still ::1 (see here)
• After the previously mentioned change, the default will still take precedence

Workaround: Pass -e WAKAPI_LISTEN_IPV6='-' to docker run.

Solution: I'll push a new image in a second.

[muety]

Opened jinzhu/configor#89.

[libukai]

After upgrading to 2.10.2, in the Docker logs, I can see the reported heartbeat data, but there is no record or error in the PostgreSQL database.

[libukai]

Even if downgraded to 2.10.0, it is still unable to record data. Is it because the database structure was damaged during the upgrade process? However, currently, it seems that the historical data is still intact, only the new data cannot be recorded.

[DenuxPlays]

Even if downgraded to 2.10.0, it is still unable to record data. Is it because the database structure was damaged during the upgrade process? However, currently, it seems that the historical data is still intact, only the new data cannot be recorded.

I guess you should open a new issue for that.
Seems unrelated as I had no problems since 2.10.2

[muety]

There haven't been any changes to the database schema or the heartbeats ingestion mechanism between 2.10.0 and 2.10.2. No idea why you neither get the heartbeats, nor an error message. If the endpoint returns 201, it means everything went well on the way.

Can you please double-check, if:

• ... there are no entries in the heartbeats table after the point in time where you upgraded
• ... the heartbeats endpoint returns an empty list after that point in time
• ... the summary on your dashboard shows zero hours since then

[libukai]

Today everything is back to normal, including yesterday's data..

Thank you for your reply, thank you for open sourcing such a useful tool