vikunja
/
vikunja
6
43
Fork 70
Code Issues 150 Pull Requests 13 Packages Releases 32 Activity

Server Side Caching not working as intended #1779

New Issue
Closed
opened 2021-04-15 21:01:11 +00:00 by danner26 · 10 comments
danner26 commented 2021-04-15 21:01:11 +00:00
Copy Link

I found that when you have in-memory caching enabled on the server, task labels become duplicated. When you create a label, navigate away and then come back it duplicates the labels. Please see these 2 images for instance:
image
image

Here is my config.yml:

service:
    JWTSecret: REDACTED_512_SECRET
    frontendurl: REDACTED
    motd: REDACTED
    timezone: EST
    enableregistration: false
cache:
    enabled: true
    type: keyvalue
cors:
    enable: true
    origins: REDACTED
    maxage: 300
mailer:
    enabled: true
    host: REDACTED
    port: REDACTED
    username: REDACTED
    password: REDACTED
    fromemail: REDACTED
    forcessl: yes
keyvalue:
    type: memory
metrics:
    enabled: true
    username: REDACTED
    password: REDACTED

The first response from the server on the list page (before duplication) looks like the following code snippet. This is the request that shows a valid list/label group.

[{"id":7,"title":"test","description":"","done":false,"done_at":"0001-01-01T00:00:00Z","due_date":"0001-01-01T00:00:00Z","reminder_dates":null,"list_id":2,"repeat_after":0,"repeat_mode":0,"priority":0,"start_date":"0001-01-01T00:00:00Z","end_date":"0001-01-01T00:00:00Z","assignees":null,"labels":[{"id":4,"title":"test","description":"","hex_color":"e8e8e8","created_by":{"id":1,"name":"REDACTED_NAME","username":"REDACTED_USERNAME","created":"2021-04-15T13:27:38-05:00","updated":"2021-04-15T13:55:58-05:00"},"created":"2021-04-15T15:54:19-05:00","updated":"2021-04-15T15:54:19-05:00"}],"hex_color":"198cff","percent_done":0,"identifier":"-1","index":1,"related_tasks":{},"attachments":null,"is_favorite":false,"created":"2021-04-15T15:54:10-05:00","updated":"2021-04-15T15:54:20-05:00","bucket_id":2,"position":65536,"created_by":{"id":1,"name":"REDACTED_NAME","username":"REDACTED_USERNAME","created":"2021-04-15T13:27:38-05:00","updated":"2021-04-15T13:55:58-05:00"}}]

On the second request (after duplication) this what we recieve:

[{"id":7,"title":"test","description":"","done":false,"done_at":"0001-01-01T00:00:00Z","due_date":"0001-01-01T00:00:00Z","reminder_dates":null,"list_id":2,"repeat_after":0,"repeat_mode":0,"priority":0,"start_date":"0001-01-01T00:00:00Z","end_date":"0001-01-01T00:00:00Z","assignees":null,"labels":[{"id":4,"title":"test","description":"","hex_color":"e8e8e8","created_by":{"id":1,"name":"REDACTED_NAME","username":"REDACTED_USERNAME","created":"2021-04-15T13:27:38-05:00","updated":"2021-04-15T13:55:58-05:00"},"created":"2021-04-15T15:54:19-05:00","updated":"2021-04-15T15:54:19-05:00"},{"id":4,"title":"test","description":"","hex_color":"e8e8e8","created_by":{"id":1,"name":"REDACTED_NAME","username":"REDACTED_USERNAME","created":"2021-04-15T13:27:38-05:00","updated":"2021-04-15T13:55:58-05:00"},"created":"2021-04-15T15:54:19-05:00","updated":"2021-04-15T15:54:19-05:00"},{"id":4,"title":"test","description":"","hex_color":"e8e8e8","created_by":{"id":1,"name":"REDACTED_NAME","username":"REDACTED_USERNAME","created":"2021-04-15T13:27:38-05:00","updated":"2021-04-15T13:55:58-05:00"},"created":"2021-04-15T15:54:19-05:00","updated":"2021-04-15T15:54:19-05:00"}],"hex_color":"198cff","percent_done":0,"identifier":"-1","index":1,"related_tasks":{},"attachments":null,"is_favorite":false,"created":"2021-04-15T15:54:10-05:00","updated":"2021-04-15T15:54:20-05:00","bucket_id":2,"position":65536,"created_by":{"id":1,"name":"REDACTED_NAME","username":"REDACTED_USERNAME","created":"2021-04-15T13:27:38-05:00","updated":"2021-04-15T13:55:58-05:00"}}]

Disabling cache in the config.yml resolves the issue completely, even after multiple page changes/reloads (as expected):

[{"id":7,"title":"test","description":"","done":false,"done_at":"0001-01-01T00:00:00Z","due_date":"0001-01-01T00:00:00Z","reminder_dates":null,"list_id":2,"repeat_after":0,"repeat_mode":0,"priority":0,"start_date":"0001-01-01T00:00:00Z","end_date":"0001-01-01T00:00:00Z","assignees":null,"labels":[{"id":4,"title":"test","description":"","hex_color":"e8e8e8","created_by":{"id":1,"name":"REDACTED_NAME","username":"REDACTED_USERNAME","created":"2021-04-15T13:27:38-05:00","updated":"2021-04-15T13:55:58-05:00"},"created":"2021-04-15T15:54:19-05:00","updated":"2021-04-15T15:54:19-05:00"}],"hex_color":"198cff","percent_done":0,"identifier":"-1","index":1,"related_tasks":{},"attachments":null,"is_favorite":false,"created":"2021-04-15T15:54:10-05:00","updated":"2021-04-15T15:54:20-05:00","bucket_id":2,"position":65536,"created_by":{"id":1,"name":"REDACTED_NAME","username":"REDACTED_USERNAME","created":"2021-04-15T13:27:38-05:00","updated":"2021-04-15T13:55:58-05:00"}}]

It appears that the backend caching on the server side is keeping multiple records of the same data, without either updating or replacing (appending instead). I am not sure if this is a misconfiguration on my part. I am running the backend and frontend using docker, and a reverse proxy in front of both with the proper nginx rules setup.

I found that when you have in-memory caching enabled on the server, task labels become duplicated. When you create a label, navigate away and then come back it duplicates the labels. Please see these 2 images for instance: ![image](/attachments/485426f8-6f14-4205-956f-404ea8c0af0f) ![image](/attachments/e62a9dcb-ccaa-4454-9ad0-79b9859920da) Here is my config.yml: ``` service: JWTSecret: REDACTED_512_SECRET frontendurl: REDACTED motd: REDACTED timezone: EST enableregistration: false cache: enabled: true type: keyvalue cors: enable: true origins: REDACTED maxage: 300 mailer: enabled: true host: REDACTED port: REDACTED username: REDACTED password: REDACTED fromemail: REDACTED forcessl: yes keyvalue: type: memory metrics: enabled: true username: REDACTED password: REDACTED ``` The first response from the server on the list page (before duplication) looks like the following code snippet. This is the request that shows a valid list/label group. ``` [{"id":7,"title":"test","description":"","done":false,"done_at":"0001-01-01T00:00:00Z","due_date":"0001-01-01T00:00:00Z","reminder_dates":null,"list_id":2,"repeat_after":0,"repeat_mode":0,"priority":0,"start_date":"0001-01-01T00:00:00Z","end_date":"0001-01-01T00:00:00Z","assignees":null,"labels":[{"id":4,"title":"test","description":"","hex_color":"e8e8e8","created_by":{"id":1,"name":"REDACTED_NAME","username":"REDACTED_USERNAME","created":"2021-04-15T13:27:38-05:00","updated":"2021-04-15T13:55:58-05:00"},"created":"2021-04-15T15:54:19-05:00","updated":"2021-04-15T15:54:19-05:00"}],"hex_color":"198cff","percent_done":0,"identifier":"-1","index":1,"related_tasks":{},"attachments":null,"is_favorite":false,"created":"2021-04-15T15:54:10-05:00","updated":"2021-04-15T15:54:20-05:00","bucket_id":2,"position":65536,"created_by":{"id":1,"name":"REDACTED_NAME","username":"REDACTED_USERNAME","created":"2021-04-15T13:27:38-05:00","updated":"2021-04-15T13:55:58-05:00"}}] ``` On the second request (after duplication) this what we recieve: ``` [{"id":7,"title":"test","description":"","done":false,"done_at":"0001-01-01T00:00:00Z","due_date":"0001-01-01T00:00:00Z","reminder_dates":null,"list_id":2,"repeat_after":0,"repeat_mode":0,"priority":0,"start_date":"0001-01-01T00:00:00Z","end_date":"0001-01-01T00:00:00Z","assignees":null,"labels":[{"id":4,"title":"test","description":"","hex_color":"e8e8e8","created_by":{"id":1,"name":"REDACTED_NAME","username":"REDACTED_USERNAME","created":"2021-04-15T13:27:38-05:00","updated":"2021-04-15T13:55:58-05:00"},"created":"2021-04-15T15:54:19-05:00","updated":"2021-04-15T15:54:19-05:00"},{"id":4,"title":"test","description":"","hex_color":"e8e8e8","created_by":{"id":1,"name":"REDACTED_NAME","username":"REDACTED_USERNAME","created":"2021-04-15T13:27:38-05:00","updated":"2021-04-15T13:55:58-05:00"},"created":"2021-04-15T15:54:19-05:00","updated":"2021-04-15T15:54:19-05:00"},{"id":4,"title":"test","description":"","hex_color":"e8e8e8","created_by":{"id":1,"name":"REDACTED_NAME","username":"REDACTED_USERNAME","created":"2021-04-15T13:27:38-05:00","updated":"2021-04-15T13:55:58-05:00"},"created":"2021-04-15T15:54:19-05:00","updated":"2021-04-15T15:54:19-05:00"}],"hex_color":"198cff","percent_done":0,"identifier":"-1","index":1,"related_tasks":{},"attachments":null,"is_favorite":false,"created":"2021-04-15T15:54:10-05:00","updated":"2021-04-15T15:54:20-05:00","bucket_id":2,"position":65536,"created_by":{"id":1,"name":"REDACTED_NAME","username":"REDACTED_USERNAME","created":"2021-04-15T13:27:38-05:00","updated":"2021-04-15T13:55:58-05:00"}}] ``` Disabling cache in the config.yml resolves the issue completely, even after multiple page changes/reloads (as expected): ``` [{"id":7,"title":"test","description":"","done":false,"done_at":"0001-01-01T00:00:00Z","due_date":"0001-01-01T00:00:00Z","reminder_dates":null,"list_id":2,"repeat_after":0,"repeat_mode":0,"priority":0,"start_date":"0001-01-01T00:00:00Z","end_date":"0001-01-01T00:00:00Z","assignees":null,"labels":[{"id":4,"title":"test","description":"","hex_color":"e8e8e8","created_by":{"id":1,"name":"REDACTED_NAME","username":"REDACTED_USERNAME","created":"2021-04-15T13:27:38-05:00","updated":"2021-04-15T13:55:58-05:00"},"created":"2021-04-15T15:54:19-05:00","updated":"2021-04-15T15:54:19-05:00"}],"hex_color":"198cff","percent_done":0,"identifier":"-1","index":1,"related_tasks":{},"attachments":null,"is_favorite":false,"created":"2021-04-15T15:54:10-05:00","updated":"2021-04-15T15:54:20-05:00","bucket_id":2,"position":65536,"created_by":{"id":1,"name":"REDACTED_NAME","username":"REDACTED_USERNAME","created":"2021-04-15T13:27:38-05:00","updated":"2021-04-15T13:55:58-05:00"}}] ``` It appears that the backend caching on the server side is keeping multiple records of the same data, without either updating or replacing (appending instead). I am not sure if this is a misconfiguration on my part. I am running the backend and frontend using docker, and a reverse proxy in front of both with the proper nginx rules setup.
image.png
25 KiB
image.png
26 KiB
image.png
7.4 KiB
image.png
7.6 KiB
image.png image.png
danner26 changed title from Service Worker Caching & Config Caching Enabled to Server Side Caching not working as intended 2021-04-15 21:08:47 +00:00
konrad commented 2021-04-15 21:14:47 +00:00
Owner
Copy Link

The caching is provided by the orm layer directly so maybe that actually is a bug in there somewhere.

Could you try redis to see if it makes any difference?

In general, I found the caching nice to have but the difference in speed is usually not noticable at all. I'm running my instance and the demo one without it enabled and am still seeing < 10ms response times for most things.

The caching is provided by the orm layer directly so maybe that actually is a bug in there somewhere. Could you try redis to see if it makes any difference? In general, I found the caching nice to have but the difference in speed is usually not noticable at all. I'm running my instance and the demo one without it enabled and am still seeing < 10ms response times for most things.
danner26 commented 2021-04-15 21:25:23 +00:00
Author
Copy Link

I agree caching for this type of content on the orm layer probably wont reduce the load times much, especially since the assets are being cached by the service worker. Either way it is offered for in-memory and not working as intended so I wanted to create a ticket.

At the end of the day caching wont really be required for me, even though it would be nice. I will give redis a try and get back to you.

I agree caching for this type of content on the orm layer probably wont reduce the load times much, especially since the assets are being cached by the service worker. Either way it is offered for in-memory and not working as intended so I wanted to create a ticket. At the end of the day caching wont really be required for me, even though it would be nice. I will give redis a try and get back to you.
👍 1
konrad added the
kind/bug
 label 2021-04-15 21:39:20 +00:00
danner26 commented 2021-04-15 21:39:59 +00:00
Author
Copy Link

Looks like redis may have its own issues going on:

api_1       | 2021-04-15T21:37:52.570317971Z: ERROR     ▶ [DATABASE] 394 [redis_cacher] decode failed: gob: wrong type (models.RelatedTaskMap) for received field .RelatedTasks
frontend_1  | REDACTED_IP - - [15/Apr/2021:21:37:52 +0000] "GET /lists/2/list HTTP/1.0" 200 3650 "https://REDACTED_URL/lists/2/list" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.128 Safari/537.36" "REDACTED_IP"
proxy_1     | REDACTED_IP - - [15/Apr/2021:21:37:52 +0000] "GET /lists/2/list HTTP/1.1" 200 3650 "https://REDACTED_URL/lists/2/list" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.128 Safari/537.36" "REDACTED_IP"
api_1       | 2021-04-15T21:37:52.580304765Z: ERROR     ▶ [DATABASE] 3b6 [redis_cacher] decode failed: gob: wrong type (models.RelatedTaskMap) for received field .RelatedTasks
api_1       | 2021-04-15T21:37:52.580783348Z: WEB       ▶ REDACTED_IP  GET 200 /api/v1/notifications?page=1 6.764758ms - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.128 Safari/537.36
api_1       | 2021-04-15T21:37:52.582621163Z: ERROR     ▶ [DATABASE] 3be [redis_cacher] decode failed: gob: wrong type (models.RelatedTaskMap) for received field .RelatedTasks
proxy_1     | REDACTED_IP - - [15/Apr/2021:21:37:52 +0000] "GET /api/v1/notifications?page=1 HTTP/1.1" 200 565 "https://REDACTED_URL/lists/2/list" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.128 Safari/537.36" "REDACTED_IP"
api_1       | 2021-04-15T21:37:52.592035285Z: ERROR     ▶ [DATABASE] 3e6 [redis_cacher] decode failed: gob: wrong type (models.RelatedTaskMap) for received field .RelatedTasks
api_1       | 2021-04-15T21:37:52.593809131Z: ERROR     ▶ [DATABASE] 3ee [redis_cacher] decode failed: gob: wrong type (models.RelatedTaskMap) for received field .RelatedTasks
api_1       | 2021-04-15T21:37:52.598745274Z: WEB       ▶ REDACTED_IP  GET 200 /api/v1/lists/2 21.18648ms - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.128 Safari/537.36
proxy_1     | REDACTED_IP - - [15/Apr/2021:21:37:52 +0000] "GET /api/v1/lists/2 HTTP/1.1" 200 375 "https://REDACTED_URL/lists/2/list" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.128 Safari/537.36" "REDACTED_IP"
api_1       | 2021-04-15T21:37:52.604908091Z: ERROR     ▶ [DATABASE] 417 [redis_cacher] decode failed: gob: wrong type (models.RelatedTaskMap) for received field .RelatedTasks

Could be my implementation but I do not think so.. there is no authentication for this redis server, and it is a local docker container as well. Any ideas on that?

To make it a bit easier to read, this is the only error in that dump:

[redis_cacher] decode failed: gob: wrong type (models.RelatedTaskMap) for received field .RelatedTasks
Looks like redis may have its own issues going on: ``` api_1 | 2021-04-15T21:37:52.570317971Z: ERROR ▶ [DATABASE] 394 [redis_cacher] decode failed: gob: wrong type (models.RelatedTaskMap) for received field .RelatedTasks frontend_1 | REDACTED_IP - - [15/Apr/2021:21:37:52 +0000] "GET /lists/2/list HTTP/1.0" 200 3650 "https://REDACTED_URL/lists/2/list" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.128 Safari/537.36" "REDACTED_IP" proxy_1 | REDACTED_IP - - [15/Apr/2021:21:37:52 +0000] "GET /lists/2/list HTTP/1.1" 200 3650 "https://REDACTED_URL/lists/2/list" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.128 Safari/537.36" "REDACTED_IP" api_1 | 2021-04-15T21:37:52.580304765Z: ERROR ▶ [DATABASE] 3b6 [redis_cacher] decode failed: gob: wrong type (models.RelatedTaskMap) for received field .RelatedTasks api_1 | 2021-04-15T21:37:52.580783348Z: WEB ▶ REDACTED_IP GET 200 /api/v1/notifications?page=1 6.764758ms - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.128 Safari/537.36 api_1 | 2021-04-15T21:37:52.582621163Z: ERROR ▶ [DATABASE] 3be [redis_cacher] decode failed: gob: wrong type (models.RelatedTaskMap) for received field .RelatedTasks proxy_1 | REDACTED_IP - - [15/Apr/2021:21:37:52 +0000] "GET /api/v1/notifications?page=1 HTTP/1.1" 200 565 "https://REDACTED_URL/lists/2/list" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.128 Safari/537.36" "REDACTED_IP" api_1 | 2021-04-15T21:37:52.592035285Z: ERROR ▶ [DATABASE] 3e6 [redis_cacher] decode failed: gob: wrong type (models.RelatedTaskMap) for received field .RelatedTasks api_1 | 2021-04-15T21:37:52.593809131Z: ERROR ▶ [DATABASE] 3ee [redis_cacher] decode failed: gob: wrong type (models.RelatedTaskMap) for received field .RelatedTasks api_1 | 2021-04-15T21:37:52.598745274Z: WEB ▶ REDACTED_IP GET 200 /api/v1/lists/2 21.18648ms - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.128 Safari/537.36 proxy_1 | REDACTED_IP - - [15/Apr/2021:21:37:52 +0000] "GET /api/v1/lists/2 HTTP/1.1" 200 375 "https://REDACTED_URL/lists/2/list" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.128 Safari/537.36" "REDACTED_IP" api_1 | 2021-04-15T21:37:52.604908091Z: ERROR ▶ [DATABASE] 417 [redis_cacher] decode failed: gob: wrong type (models.RelatedTaskMap) for received field .RelatedTasks ``` Could be my implementation but I do not think so.. there is no authentication for this redis server, and it is a local docker container as well. Any ideas on that? To make it a bit easier to read, this is the only error in that dump: ``` [redis_cacher] decode failed: gob: wrong type (models.RelatedTaskMap) for received field .RelatedTasks ```
konrad commented 2021-04-15 21:44:05 +00:00
Owner
Copy Link

AFAIU even though this is an error it should still cache things. I've asked the xorm guys a while back about this but they didn't have a good idea either. Not quite sure where to look.

Does the issue you originally reported still happen?

In the (far away) future I'd like to get rid of the orm caching and cache stuff in Vikunja directly but there's a lot of other stuff that is more important than this so that wont happen any time in the next months.

AFAIU even though this is an error it should still cache things. I've asked the xorm guys a while back about this but they didn't have a good idea either. Not quite sure where to look. Does the issue you originally reported still happen? In the (far away) future I'd like to get rid of the orm caching and cache stuff in Vikunja directly but there's a lot of other stuff that is more important than this so that wont happen any time in the next months.
danner26 commented 2021-04-15 21:48:23 +00:00
Author
Copy Link

This is a fresh install of redis, nothing else using the service.
Some more details from redis side of things:
keys*

127.0.0.1:6379> keys *
 1) "xorm:sql:lists:3027824172"
 2) "xorm:sql:saved_filters:3922608160"
 3) "xorm:bean:lists:\x10\xff\x81\x02\x01\x01\x02PK\x01\xff\x82\x00\x01\x10\x00\x00\x0e\xff\x82\x00\x01\x05int64\x04\x02\x00\x02"
 4) "xorm:bean:notifications:\x10\xff\x81\x02\x01\x01\x02PK\x01\xff\x82\x00\x01\x10\x00\x00\x0e\xff\x82\x00\x01\x05int64\x04\x02\x00\x02"
 5) "xorm:sql:task_reminders:2706106389"
 6) "xorm:sql:tasks:3795459004"
 7) "xorm:sql:subscriptions:1606035003"
 8) "xorm:sql:users:29866484"
 9) "xorm:sql:lists:2635114230"
10) "xorm:sql:users:2843061681"
11) "xorm:sql:task_relations:4191207804"
12) "xorm:sql:lists:1232550842"
13) "xorm:sql:users:516001826"
14) "xorm:sql:unsplash_photos:2702400236"
15) "xorm:bean:lists:\x10\xff\x81\x02\x01\x01\x02PK\x01\xff\x82\x00\x01\x10\x00\x00\x0e\xff\x82\x00\x01\x05int64\x04\x02\x00\x04"
16) "xorm:bean:users:\x10\xff\x81\x02\x01\x01\x02PK\x01\xff\x82\x00\x01\x10\x00\x00\x0e\xff\x82\x00\x01\x05int64\x04\x02\x00\x02"
17) "xorm:sql:users:4186005587"
18) "xorm:bean:tasks:\x10\xff\x81\x02\x01\x01\x02PK\x01\xff\x82\x00\x01\x10\x00\x00\x0e\xff\x82\x00\x01\x05int64\x04\x02\x00\x0e"
19) "xorm:sql:task_attachments:24396998"
20) "xorm:sql:notifications:2571868094"

and

127.0.0.1:6379> select 1
OK
127.0.0.1:6379[1]> keys *
(empty array)
127.0.0.1:6379[1]> select 3
OK
127.0.0.1:6379[3]> keys *
(empty array)
127.0.0.1:6379[3]> select 6
OK
127.0.0.1:6379[6]> keys *
(empty array)
127.0.0.1:6379[6]> select 9
OK
127.0.0.1:6379[9]> keys *
(empty array)
127.0.0.1:6379[9]> select 11
OK
127.0.0.1:6379[11]> keys *
(empty array)
127.0.0.1:6379[11]> select 12
OK
127.0.0.1:6379[12]> keys *
(empty array)
127.0.0.1:6379[12]> select 15
OK
127.0.0.1:6379[15]> keys *
(empty array)
This is a fresh install of redis, nothing else using the service. Some more details from redis side of things: keys* ``` 127.0.0.1:6379> keys * 1) "xorm:sql:lists:3027824172" 2) "xorm:sql:saved_filters:3922608160" 3) "xorm:bean:lists:\x10\xff\x81\x02\x01\x01\x02PK\x01\xff\x82\x00\x01\x10\x00\x00\x0e\xff\x82\x00\x01\x05int64\x04\x02\x00\x02" 4) "xorm:bean:notifications:\x10\xff\x81\x02\x01\x01\x02PK\x01\xff\x82\x00\x01\x10\x00\x00\x0e\xff\x82\x00\x01\x05int64\x04\x02\x00\x02" 5) "xorm:sql:task_reminders:2706106389" 6) "xorm:sql:tasks:3795459004" 7) "xorm:sql:subscriptions:1606035003" 8) "xorm:sql:users:29866484" 9) "xorm:sql:lists:2635114230" 10) "xorm:sql:users:2843061681" 11) "xorm:sql:task_relations:4191207804" 12) "xorm:sql:lists:1232550842" 13) "xorm:sql:users:516001826" 14) "xorm:sql:unsplash_photos:2702400236" 15) "xorm:bean:lists:\x10\xff\x81\x02\x01\x01\x02PK\x01\xff\x82\x00\x01\x10\x00\x00\x0e\xff\x82\x00\x01\x05int64\x04\x02\x00\x04" 16) "xorm:bean:users:\x10\xff\x81\x02\x01\x01\x02PK\x01\xff\x82\x00\x01\x10\x00\x00\x0e\xff\x82\x00\x01\x05int64\x04\x02\x00\x02" 17) "xorm:sql:users:4186005587" 18) "xorm:bean:tasks:\x10\xff\x81\x02\x01\x01\x02PK\x01\xff\x82\x00\x01\x10\x00\x00\x0e\xff\x82\x00\x01\x05int64\x04\x02\x00\x0e" 19) "xorm:sql:task_attachments:24396998" 20) "xorm:sql:notifications:2571868094" ``` and ``` 127.0.0.1:6379> select 1 OK 127.0.0.1:6379[1]> keys * (empty array) 127.0.0.1:6379[1]> select 3 OK 127.0.0.1:6379[3]> keys * (empty array) 127.0.0.1:6379[3]> select 6 OK 127.0.0.1:6379[6]> keys * (empty array) 127.0.0.1:6379[6]> select 9 OK 127.0.0.1:6379[9]> keys * (empty array) 127.0.0.1:6379[9]> select 11 OK 127.0.0.1:6379[11]> keys * (empty array) 127.0.0.1:6379[11]> select 12 OK 127.0.0.1:6379[12]> keys * (empty array) 127.0.0.1:6379[12]> select 15 OK 127.0.0.1:6379[15]> keys * (empty array) ```
danner26 commented 2021-04-15 21:52:09 +00:00
Author
Copy Link

The issue is still present with in-memory caching and it appears that redis caching does not work, at least not in a dockerized setup like this. Right now disabling caching is the best route.

I agree caching on the vikunja side would be optimal, but at the end of the day of course there are more important tasks. I suppose this will be one of those issues that remains open for a while lol

The issue is still present with in-memory caching and it appears that redis caching does not work, at least not in a dockerized setup like this. Right now disabling caching is the best route. I agree caching on the vikunja side would be optimal, but at the end of the day of course there are more important tasks. I suppose this will be one of those issues that remains open for a while lol
konrad commented 2021-04-15 21:58:20 +00:00
Owner
Copy Link

Yeah I guess this will be open for a while (that is, unless you want to dive in and send a PR 🙂 )

In a best case scenario this would get fixed by xorm without any doings on our side.

Yeah I guess this will be open for a while (that is, unless you want to dive in and send a PR 🙂 ) In a best case scenario this would get fixed by xorm without any doings on our side.
👍 1
danner26 commented 2021-04-15 22:00:46 +00:00
Author
Copy Link

If I get time to look into redis/the memory caching I will submit a PR.. if I get anywhere. Between work and this masters program, development time has been sevearly reduced :(

That would be nice. I find it rarely happens though lol

If I get time to look into redis/the memory caching I will submit a PR.. if I get anywhere. Between work and this masters program, development time has been sevearly reduced :( That would be nice. I find it rarely happens though lol
👍 1
konrad commented 2021-04-16 07:40:53 +00:00
Owner
Copy Link

I find it rarely happens though lol

Well at least you were able to reproduce it, that's something.

> I find it rarely happens though lol Well at least you were able to reproduce it, that's something.
👍 1
konrad commented 2021-08-17 19:29:39 +00:00
Owner
Copy Link

Closing this due to inactivity - please feel free to reopen if this is still relevant and reproducable with the latest version (on try for example).

Closing this due to inactivity - please feel free to reopen if this is still relevant and reproducable with the latest version (on [try](https://try.vikunja.io) for example).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
main
renovate/camel-case-5.x
renovate/go-1.x
renovate/lowlight-3.x
renovate/golang.org-x-sync-0.x
renovate/major-dev-dependencies
renovate/github.com-wneessen-go-mail-0.x
renovate/golangci-golangci-lint-1.x
feature/better-filter-syntax
fix/tiptap-task-list
renovate/flexsearch-0.x
feature/zod-schema
renovate/github.com-typesense-typesense-go-1.x
renovate/github.com-golang-jwt-jwt-v4-5.x
automatic-year-range-for-go-header-template
feature/hide-forbidden-related-tasks
renovate/golang-1.x
release/0.20
release/0.17
release/0.16
release/0.15
release/0.14
release/0.13
v0.23.0
v0.22.1
v0.22.0
v0.21.0
v0.20.4
v0.20.3
v0.20.2
v0.20.1
v0.20.0
v0.19.2
v0.19.1
v0.19.0
v0.18.1
v0.18.0
v0.17.1
v0.17.0
v0.16.1
v0.16.0
v0.15.1
v0.15.0
v0.14.1
v0.14.0
v0.13.1
v0.13
v0.12
v0.11
v0.10
v0.9
v0.8
v0.7
v0.6
v0.5
v0.4
v0.3
v0.2
v0.1
Labels
Clear labels   
dependencies

   
duplicate

This issue or pull request already exists

  
help wanted

Need some help

  
invalid

Something is wrong

  
kind/bug

Something is not working

  
kind/feature

New feature

  
needs reproduction

   
question

More information is needed

  
security

   
wontfix

This won't be fixed

No Label
dependencies
duplicate
help wanted
invalid
kind/bug
kind/feature
needs reproduction
question
security
wontfix
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: vikunja/vikunja#1779
No description provided.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?