Adding task relation results in 500 internal server error #1119

New Issue

instag1b · 2022-02-10T20:13:48Z

instag1b commented

2022-02-10 20:13:48 +00:00

Expected behaviour

Adding a task relation should not result in an internal server error.

Actual behaviour

As soon as I navigate away from a task after adding a task relation, an error message is displayed in the bottom left corner:

The following error message is logged:

2022-02-10T18:53:44.38472852Z: WEB 	▶ 10.1.0.103  GET 200 /api/v1/tasks/all?s=fco&page=1 4.688113ms - Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Firefox/91.0
2022-02-10T18:53:49.671175315Z: WEB 	▶ 10.1.0.103  PUT 201 /api/v1/tasks/3/relations 12.937366ms - Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Firefox/91.0
2022-02-10T18:53:50.508913209Z: WEB 	▶ 10.1.0.103  GET 200 /api/v1/notifications?page=1 624.942µs - Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Firefox/91.0
2022-02-10T18:53:56.97782715Z: WEB 	▶ 10.1.0.103  GET 200 /api/v1/lists/2 2.456208ms - Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Firefox/91.0
2022-02-10T18:53:56.982096468Z: ERROR	▶ handler/ReadAllWeb 48f json: unsupported value: encountered a cycle via *models.Task
2022-02-10T18:53:56.982217896Z: WEB 	▶ 10.1.0.103  GET 500 /api/v1/lists/2/tasks?sort_by[]=position&sort_by[]=id&order_by[]=asc&order_by[]=desc&filter_by[]=done&filter_value[]=false&filter_comparator[]=equals&filter_concat=and&page=1 6.846001ms - Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Firefox/91.0

The list becomes completely inaccessible and cannot be deleted unless I delete the whole namespace containing the list. Other lists in the same namespace are not affected.

The error does not occur when trying the same on the demo instance (try.vikunja.io).

Steps to reproduce

Create a namespace
Create a list in the created namespace
Create two tasks in the created list
Add a task relation between both tasks (e.g. "Subtask", "Parent Task", "Blocked By")
Return to the list
Receive error message

Additional information

Vikunja is accessed using Firefox 96.0.3 with all content blockers disabled.

config.yaml:

---
log:
  path: /var/log/
  level: "DEBUG"
  eventslevel: "DEBUG"

service:
  frontendurl: "https://vikunja.domain.com"
  enablelinksharing: true
  enableregistration: false
  enabletaskattachments: true
  timezone: Europe/Amsterdam
  enabletaskcomments: true
  enabletotp: false

database:
  type: "mysql"
  user: "vikunja"
  password: "REDACTED"
  host: "vikunja-db"
  database: "vikunja"
  maxopenconnections: 100
  maxidleconnections: 50
  maxconnectionlifetime: 10000
  sslmode: disable
  tls: false

cache:
  enabled: true
  type: keyvalue
  maxelementsize: 1000

cors:
  enable: true
  origins:
    - "https://vikunja.domain.com"
  maxage: 0

files:
  basepath: ./files # relative to the binary
  maxsize: 20MB

avatar:
  gravatarexpiration: 3600

backgrounds:
  enabled: true
  providers:
    upload:
      enabled: true

keyvalue:
  type: "memory"

auth:
  local:
    enabled: false
  openid:
    enabled: true
    providers:
      - name: Keyloak
        authurl: https://keycloak.domain.com/auth/realms/my-realm
        clientid: vikunja
        clientsecret: REDACTED

docker-compose.yaml:

---
version: '2'

services:
  db:
    image: mariadb:10.7.1
    command:  --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
    container_name: vikunja-db
    environment:
      - MARIADB_ROOT_PASSWORD_FILE=/run/secrets/root_pw
      - MYSQL_DATABASE=vikunja
      - MYSQL_USER=vikunja
      - MYSQL_PASSWORD_FILE=/run/secrets/db_pw
    networks:
      - vikunja_net
    restart: unless-stopped
    volumes:
      - vikunja_db:/var/lib/mysql
      - ./secrets/mariadb:/run/secrets:ro,Z

  api:
    image: vikunja/api:0.18.1
    container_name: vikunja-api
    depends_on:
      - db
    networks:
      - traefik_net
      - vikunja_net
    restart: unless-stopped
    volumes:
      - vikunja:/app/vikunja/files
      - ./config.yaml:/etc/vikunja/config.yml:ro,Z
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.vikunja-api.entrypoints=https"
      - "traefik.http.routers.vikunja-api.rule=Host(`vikunja.domain.com`) && PathPrefix(`/api/v1`, `/dav/`, `/.well-known/`)"
      - "traefik.http.routers.vikunja-api.tls=true"
      - "traefik.http.services.vikunja-api.loadbalancer.server.port=3456"

  frontend:
    image: vikunja/frontend:0.18.2
    container_name: vikunja-frontend
    networks:
      - traefik_net
    restart: unless-stopped
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.vikunja.entrypoints=https"
      - "traefik.http.routers.vikunja.rule=Host(`vikunja.domain.com`)"
      - "traefik.http.routers.vikunja.tls=true"
      - "traefik.http.services.vikunja.loadbalancer.server.port=80"

networks:
  traefik_net:
    external:
      name: traefik_net
  vikunja_net:

volumes:
  vikunja:
  vikunja_db:

API image digest: sha256:8ea38476894b1bed7f412e9a1280cc3271ec4f0d80decc2fc93caea13c0183cf
Frontend image digest: sha256:26ccd3b4d7c43c1e99d00924d2a76a630e03de690771aa48fb111875cec29f60

### Expected behaviour Adding a task relation should not result in an internal server error. ### Actual behaviour As soon as I navigate away from a task after adding a task relation, an error message is displayed in the bottom left corner: ![image](/attachments/205606c7-340a-46da-aec2-8d9aa1528ea8) The following error message is logged: ``` 2022-02-10T18:53:44.38472852Z: WEB ▶ 10.1.0.103 GET 200 /api/v1/tasks/all?s=fco&page=1 4.688113ms - Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Firefox/91.0 2022-02-10T18:53:49.671175315Z: WEB ▶ 10.1.0.103 PUT 201 /api/v1/tasks/3/relations 12.937366ms - Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Firefox/91.0 2022-02-10T18:53:50.508913209Z: WEB ▶ 10.1.0.103 GET 200 /api/v1/notifications?page=1 624.942µs - Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Firefox/91.0 2022-02-10T18:53:56.97782715Z: WEB ▶ 10.1.0.103 GET 200 /api/v1/lists/2 2.456208ms - Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Firefox/91.0 2022-02-10T18:53:56.982096468Z: ERROR ▶ handler/ReadAllWeb 48f json: unsupported value: encountered a cycle via *models.Task 2022-02-10T18:53:56.982217896Z: WEB ▶ 10.1.0.103 GET 500 /api/v1/lists/2/tasks?sort_by[]=position&sort_by[]=id&order_by[]=asc&order_by[]=desc&filter_by[]=done&filter_value[]=false&filter_comparator[]=equals&filter_concat=and&page=1 6.846001ms - Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Firefox/91.0 ``` The list becomes completely inaccessible and cannot be deleted unless I delete the whole namespace containing the list. Other lists in the same namespace are not affected. The error does not occur when trying the same on the demo instance (try.vikunja.io). ### Steps to reproduce 1. Create a namespace 2. Create a list in the created namespace 3. Create two tasks in the created list 4. Add a task relation between both tasks (e.g. "Subtask", "Parent Task", "Blocked By") 5. Return to the list 6. Receive error message ### Additional information Vikunja is accessed using Firefox `96.0.3` with all content blockers disabled. config.yaml: ``` --- log: path: /var/log/ level: "DEBUG" eventslevel: "DEBUG" service: frontendurl: "https://vikunja.domain.com" enablelinksharing: true enableregistration: false enabletaskattachments: true timezone: Europe/Amsterdam enabletaskcomments: true enabletotp: false database: type: "mysql" user: "vikunja" password: "REDACTED" host: "vikunja-db" database: "vikunja" maxopenconnections: 100 maxidleconnections: 50 maxconnectionlifetime: 10000 sslmode: disable tls: false cache: enabled: true type: keyvalue maxelementsize: 1000 cors: enable: true origins: - "https://vikunja.domain.com" maxage: 0 files: basepath: ./files # relative to the binary maxsize: 20MB avatar: gravatarexpiration: 3600 backgrounds: enabled: true providers: upload: enabled: true keyvalue: type: "memory" auth: local: enabled: false openid: enabled: true providers: - name: Keyloak authurl: https://keycloak.domain.com/auth/realms/my-realm clientid: vikunja clientsecret: REDACTED ``` docker-compose.yaml: ``` --- version: '2' services: db: image: mariadb:10.7.1 command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci container_name: vikunja-db environment: - MARIADB_ROOT_PASSWORD_FILE=/run/secrets/root_pw - MYSQL_DATABASE=vikunja - MYSQL_USER=vikunja - MYSQL_PASSWORD_FILE=/run/secrets/db_pw networks: - vikunja_net restart: unless-stopped volumes: - vikunja_db:/var/lib/mysql - ./secrets/mariadb:/run/secrets:ro,Z api: image: vikunja/api:0.18.1 container_name: vikunja-api depends_on: - db networks: - traefik_net - vikunja_net restart: unless-stopped volumes: - vikunja:/app/vikunja/files - ./config.yaml:/etc/vikunja/config.yml:ro,Z labels: - "traefik.enable=true" - "traefik.http.routers.vikunja-api.entrypoints=https" - "traefik.http.routers.vikunja-api.rule=Host(`vikunja.domain.com`) && PathPrefix(`/api/v1`, `/dav/`, `/.well-known/`)" - "traefik.http.routers.vikunja-api.tls=true" - "traefik.http.services.vikunja-api.loadbalancer.server.port=3456" frontend: image: vikunja/frontend:0.18.2 container_name: vikunja-frontend networks: - traefik_net restart: unless-stopped labels: - "traefik.enable=true" - "traefik.http.routers.vikunja.entrypoints=https" - "traefik.http.routers.vikunja.rule=Host(`vikunja.domain.com`)" - "traefik.http.routers.vikunja.tls=true" - "traefik.http.services.vikunja.loadbalancer.server.port=80" networks: traefik_net: external: name: traefik_net vikunja_net: volumes: vikunja: vikunja_db: ``` API image digest: `sha256:8ea38476894b1bed7f412e9a1280cc3271ec4f0d80decc2fc93caea13c0183cf` Frontend image digest: `sha256:26ccd3b4d7c43c1e99d00924d2a76a630e03de690771aa48fb111875cec29f60`

image.png

5.2 KiB

instag1b commented

2022-02-10 20:26:17 +00:00

I just tried the unstable image tags - same error. Version is now the same as the demo instance (Frontend Version: 0.18.1+1101-8f726e17ef, API Version: v0.18.1+169-7978c91d09) as of now.

I just tried the `unstable` image tags - same error. Version is now the same as the demo instance (Frontend Version: `0.18.1+1101-8f726e17ef`, API Version: `v0.18.1+169-7978c91d09`) as of now.

konrad commented

2022-02-10 22:01:37 +00:00

I was unable to reproduce this on try with the steps you provided. What was the exact relation you set between the tasks?

I was unable to reproduce this on [try](https://try.vikunja.io) with the steps you provided. What was the exact relation you set between the tasks?

konrad added the

kind/bug

label 2022-02-10 22:01:42 +00:00

instag1b commented

2022-02-10 23:47:06 +00:00

I couldn't replicate this on try.vikunja.io either. I tried the following relations: "Subtask", "Parent Task", "Blocked By" and "Related Task".
I will try to provide a more minimal working example to reproduce this issue.

I couldn't replicate this on try.vikunja.io either. I tried the following relations: "Subtask", "Parent Task", "Blocked By" and "Related Task". I will try to provide a more minimal working example to reproduce this issue.

instag1b commented

2022-02-11 00:06:06 +00:00

The issue went away after removing the following lines from my config file:

cache:
  enabled: true
  type: keyvalue
  maxelementsize: 1000

keyvalue:
  type: "memory"

Interestingly, this also resolved another issue where the same label would be displayed multiple times, adding one more each time i navigated between an issue and the task list.

Is there anything wrong with the way I configured caching?

The issue went away after removing the following lines from my config file: ``` cache: enabled: true type: keyvalue maxelementsize: 1000 keyvalue: type: "memory" ``` Interestingly, this also resolved another issue where the same label would be displayed multiple times, adding one more each time i navigated between an issue and the task list. Is there anything wrong with the way I configured caching?

konrad commented

2022-02-13 12:01:37 +00:00

I think your config is correct. This looks like a bug.

konrad referenced this issue from a commit

2022-07-07 16:34:52 +00:00

fix: cycles in tasks array when memory caching was enabled

konrad closed this issue

2022-07-07 16:34:52 +00:00

konrad commented

2022-07-07 16:35:30 +00:00

I took another look and I think I've fixed this now. Please check in ~30min with the next unstable release if the problem went away.