Error Request failed with status code 500 Internal Server Error #920

New Issue

Rustymage · 2021-07-14T10:31:35Z

Rustymage commented

2021-07-14 10:31:35 +00:00

I've been getting the following after updating ("Error Request failed with status code 500 Internal Server Error")

I cannot access any of my lists or data currently

Here is the API log:


2021/07/14 10:23:29 Config File "config" Not Found in "[/app/vikunja /etc/vikunja /app/vikunja/.config/vikunja]"
2021/07/14 10:23:29 Using default config.
2021-07-14T10:23:30.181657956Z: CRITICAL	▶ migration/Migrate 047 Migration failed: migration 20210711173657 failed: Error 1406: Data too long for column 'token' at row 1
usermod: no changes
2021/07/14 10:23:43 Config File "config" Not Found in "[/app/vikunja /etc/vikunja /app/vikunja/.config/vikunja]"
2021/07/14 10:23:43 Using default config.
2021-07-14T10:23:43.521627235Z: CRITICAL	▶ migration/Migrate 047 Migration failed: migration 20210711173657 failed: Error 1406: Data too long for column 'token' at row 1
usermod: no changes
2021/07/14 10:24:09 Config File "config" Not Found in "[/app/vikunja /etc/vikunja /app/vikunja/.config/vikunja]"
2021/07/14 10:24:09 Using default config.
2021-07-14T10:24:09.718576877Z: CRITICAL	▶ migration/Migrate 047 Migration failed: migration 20210711173657 failed: Error 1406: Data too long for column 'token' at row 1
usermod: no changes
2021/07/14 10:25:01 Config File "config" Not Found in "[/app/vikunja /etc/vikunja /app/vikunja/.config/vikunja]"
2021/07/14 10:25:01 Using default config.
2021-07-14T10:25:01.462626459Z: CRITICAL	▶ migration/Migrate 047 Migration failed: migration 20210711173657 failed: Error 1406: Data too long for column 'token' at row 1
usermod: no changes
2021/07/14 10:26:01 Config File "config" Not Found in "[/app/vikunja /etc/vikunja /app/vikunja/.config/vikunja]"
2021/07/14 10:26:01 Using default config.
2021-07-14T10:26:02.190243373Z: CRITICAL	▶ migration/Migrate 047 Migration failed: migration 20210711173657 failed: Error 1406: Data too long for column 'token' at row 1

I am going to grab the debug log if there is one and post later.

Here is the compose file:

version: '3'

services:
  api:
    image: vikunja/api:0.17.1
    environment:
      VIKUNJA_DATABASE_HOST: 192.168.1.115:3307
      VIKUNJA_DATABASE_PASSWORD: Password
      VIKUNJA_DATABASE_TYPE: mysql
      VIKUNJA_DATABASE_USER: vikunja
      VIKUNJA_DATABASE_DATABASE: vikunja
      VIKUNJA_SERVICE_ENABLEREGISTRATION: 'false'
      VIKUNJA_SERVICE_ENABLELINKSHARING: 'true'
      VIKUNJA_SERVICE_ENABLETASKATTACHMENTS: 'true'
      VIKUNJA_SERVICE_TIMEZONE: GMT
      VIKUNJA_SERVICE_ENABLETASKCOMMENTS: 'true'
      VIKUNJA_MAILER_ENABLED: 'true'
      VIKUNJA_MAILER_HOST: "smtp.gmail.com"
      VIKUNJA_MAILER_SKIPTLSVERIFY: 'false'
      VIKUNJA_MAILER_PORT: 587
      VIKUNJA_MAILER_USERNAME: "email@gmail.com"
      VIKUNJA_MAILER_PASSWORD: "Password"
      VIKUNJA_MAILER_FROMEMAIL: "mail@vikunja"
      VIKUNJA_SERVICE_FRONTENDURL: "URL.com"
      VIKUNJA_FILES_BASEPATH: ./files
      VIKUNJA_MIGRATION_TODOIST_ENABLE: 'true'
      VIKUNJA_MIGRATION_TODOIST_CLIENTID: 1234
      VIKUNJA_MIGRATION_TODOIST_CLIENTSECRET: 1234
      VIKUNJA_MIGRATION_TODOIST_REDIRECTURL: https://url.com
      VIKUNJA_LOG_PATH: ./files
      VIKUNJA_LOG_ENABLED: 'true'
      VIKUNJA_LOG_LEVEL: "ERROR"
#     VIKUNJA_SERVICE_ROOTPATH: /app/vikunja/files
    volumes:
      - ./files:/app/vikunja/files
    restart: unless-stopped
  frontend:
    image: vikunja/frontend:0.17.0
    restart: unless-stopped
  proxy:
    image: nginx
    ports:
      - 8087:80
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
    depends_on:
      - api
      - frontend
    restart: unless-stopped

I've been getting the following after updating ("`Error Request failed with status code 500 Internal Server Error`") I cannot access any of my lists or data currently Here is the API log: ``` 2021/07/14 10:23:29 Config File "config" Not Found in "[/app/vikunja /etc/vikunja /app/vikunja/.config/vikunja]" 2021/07/14 10:23:29 Using default config. 2021-07-14T10:23:30.181657956Z: CRITICAL ▶ migration/Migrate 047 Migration failed: migration 20210711173657 failed: Error 1406: Data too long for column 'token' at row 1 usermod: no changes 2021/07/14 10:23:43 Config File "config" Not Found in "[/app/vikunja /etc/vikunja /app/vikunja/.config/vikunja]" 2021/07/14 10:23:43 Using default config. 2021-07-14T10:23:43.521627235Z: CRITICAL ▶ migration/Migrate 047 Migration failed: migration 20210711173657 failed: Error 1406: Data too long for column 'token' at row 1 usermod: no changes 2021/07/14 10:24:09 Config File "config" Not Found in "[/app/vikunja /etc/vikunja /app/vikunja/.config/vikunja]" 2021/07/14 10:24:09 Using default config. 2021-07-14T10:24:09.718576877Z: CRITICAL ▶ migration/Migrate 047 Migration failed: migration 20210711173657 failed: Error 1406: Data too long for column 'token' at row 1 usermod: no changes 2021/07/14 10:25:01 Config File "config" Not Found in "[/app/vikunja /etc/vikunja /app/vikunja/.config/vikunja]" 2021/07/14 10:25:01 Using default config. 2021-07-14T10:25:01.462626459Z: CRITICAL ▶ migration/Migrate 047 Migration failed: migration 20210711173657 failed: Error 1406: Data too long for column 'token' at row 1 usermod: no changes 2021/07/14 10:26:01 Config File "config" Not Found in "[/app/vikunja /etc/vikunja /app/vikunja/.config/vikunja]" 2021/07/14 10:26:01 Using default config. 2021-07-14T10:26:02.190243373Z: CRITICAL ▶ migration/Migrate 047 Migration failed: migration 20210711173657 failed: Error 1406: Data too long for column 'token' at row 1 ``` I am going to grab the debug log if there is one and post later. Here is the compose file: ``` version: '3' services: api: image: vikunja/api:0.17.1 environment: VIKUNJA_DATABASE_HOST: 192.168.1.115:3307 VIKUNJA_DATABASE_PASSWORD: Password VIKUNJA_DATABASE_TYPE: mysql VIKUNJA_DATABASE_USER: vikunja VIKUNJA_DATABASE_DATABASE: vikunja VIKUNJA_SERVICE_ENABLEREGISTRATION: 'false' VIKUNJA_SERVICE_ENABLELINKSHARING: 'true' VIKUNJA_SERVICE_ENABLETASKATTACHMENTS: 'true' VIKUNJA_SERVICE_TIMEZONE: GMT VIKUNJA_SERVICE_ENABLETASKCOMMENTS: 'true' VIKUNJA_MAILER_ENABLED: 'true' VIKUNJA_MAILER_HOST: "smtp.gmail.com" VIKUNJA_MAILER_SKIPTLSVERIFY: 'false' VIKUNJA_MAILER_PORT: 587 VIKUNJA_MAILER_USERNAME: "email@gmail.com" VIKUNJA_MAILER_PASSWORD: "Password" VIKUNJA_MAILER_FROMEMAIL: "mail@vikunja" VIKUNJA_SERVICE_FRONTENDURL: "URL.com" VIKUNJA_FILES_BASEPATH: ./files VIKUNJA_MIGRATION_TODOIST_ENABLE: 'true' VIKUNJA_MIGRATION_TODOIST_CLIENTID: 1234 VIKUNJA_MIGRATION_TODOIST_CLIENTSECRET: 1234 VIKUNJA_MIGRATION_TODOIST_REDIRECTURL: https://url.com VIKUNJA_LOG_PATH: ./files VIKUNJA_LOG_ENABLED: 'true' VIKUNJA_LOG_LEVEL: "ERROR" # VIKUNJA_SERVICE_ROOTPATH: /app/vikunja/files volumes: - ./files:/app/vikunja/files restart: unless-stopped frontend: image: vikunja/frontend:0.17.0 restart: unless-stopped proxy: image: nginx ports: - 8087:80 volumes: - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro depends_on: - api - frontend restart: unless-stopped ```

konrad added the

kind/bug

label 2021-07-14 10:41:52 +00:00

konrad commented

2021-07-14 10:47:04 +00:00

That's interesting because you specified version 0.17.1 in your compose file but the failing migration is not in that version. Only in the unstable (latest tag in docker).

I've pushed a fix for the error from the logs in 7e229a1b83. Please try once a new unstable release is ready (should take ~30min, once this ci build passes).

I'm closing this now as resolved, feel free to reopen or ping me if it doesn't work.

That's interesting because you specified version 0.17.1 in your compose file but the failing migration is not in that version. Only in the unstable (`latest` tag in docker). I've pushed a fix for the error from the logs in 7e229a1b834c5a510664c36a52d342f0dc61e2fe. Please try once a new unstable release is ready (should take ~30min, once [this ci build](https://drone.kolaente.de/vikunja/api/3163) passes). I'm closing this now as resolved, feel free to reopen or ping me if it doesn't work.

konrad closed this issue

2021-07-14 10:47:04 +00:00

Rustymage commented

2021-07-14 10:48:55 +00:00

I did move to the latest and it broke and went back to 0.17.1 & 0.17.0 so it might be that. However, it was still broken on latest.

I will double check - thanks!

I did move to the latest and it broke and went back to 0.17.1 & 0.17.0 so it might be that. However, it was still broken on latest. I will double check - thanks!

Rustymage commented

2021-07-14 11:18:50 +00:00

With the latest release used:

2021/07/14 11:17:34 Config File "config" Not Found in "[/app/vikunja /etc/vikunja /app/vikunja/.config/vikunja]"


2021/07/14 11:17:34 Using default config.


2021-07-14T11:17:34.924743148Z: CRITICAL	▶ migration/Migrate 046 Migration failed: migration 20210711173657 failed: Error 1170: BLOB/TEXT column 'token' used in key specification without a key length

At least it's a new error now!

With the latest release used: ``` 2021/07/14 11:17:34 Config File "config" Not Found in "[/app/vikunja /etc/vikunja /app/vikunja/.config/vikunja]" 2021/07/14 11:17:34 Using default config. 2021-07-14T11:17:34.924743148Z: CRITICAL ▶ migration/Migrate 046 Migration failed: migration 20210711173657 failed: Error 1170: BLOB/TEXT column 'token' used in key specification without a key length ``` At least it's a new error now!

Rustymage reopened this issue

2021-07-14 11:18:50 +00:00

konrad commented

2021-07-14 12:49:26 +00:00

Hopefully fixed in 2a80e552cc, please try the new unstable once it's released (~30min again).

What mysql version are you running btw?

Hopefully fixed in 2a80e552cca41170726af1cad0e66a826e55d9d7, please try the new unstable once it's released (~30min again). What mysql version are you running btw?

Rustymage commented

2021-07-14 12:51:49 +00:00

Hopefully fixed in 2a80e552cc, please try the new unstable once it's released (~30min again).

What mysql version are you running btw?

Maria DB 10.3.24 on my Synology.

> Hopefully fixed in 2a80e552cca41170726af1cad0e66a826e55d9d7, please try the new unstable once it's released (~30min again). > > What mysql version are you running btw? Maria DB 10.3.24 on my Synology.

Rustymage commented

2021-07-14 13:15:54 +00:00

https://drone.kolaente.de/vikunja/api/3164 👎

konrad commented

2021-07-14 14:00:54 +00:00

Should work now (https://drone.kolaente.de/vikunja/api/3165/1/19)

Rustymage commented

2021-07-14 14:43:19 +00:00

Works - kind of.

2021-07-14T14:41:15.963131742Z: ERROR	▶ handler/ReadAllWeb 9bc Error 1054: Unknown column 'is_favorite' in 'field list'
2021-07-14T14:41:15.963324786Z: WEB 	▶ IP ADDRESS  GET 500 /api/v1/tasks/all?sort_by[]=due_date&sort_by[]=id&order_by[]=desc&order_by[]=desc&filter_by[]=done&filter_by[]=start_date&filter_by[]=end_date&filter_by[]=due_date&filter_by[]=due_date&filter_value[]=false&filter_value[]=2021-07-14T14:41:15.800Z&filter_value[]=2021-07-21T14:41:15.800Z&filter_value[]=2021-07-21T14:41:15.800Z&filter_value[]=2021-07-14T14:41:15.800Z&filter_comparator[]=equals&filter_comparator[]=greater&filter_comparator[]=less&filter_comparator[]=less&filter_comparator[]=greater&filter_concat=and&filter_include_nulls=true&page=1 12.086587ms - Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0

I seem to have lost all my tasks and the page is empty.

Works - kind of. ``` 2021-07-14T14:41:15.963131742Z: ERROR ▶ handler/ReadAllWeb 9bc Error 1054: Unknown column 'is_favorite' in 'field list' 2021-07-14T14:41:15.963324786Z: WEB ▶ IP ADDRESS GET 500 /api/v1/tasks/all?sort_by[]=due_date&sort_by[]=id&order_by[]=desc&order_by[]=desc&filter_by[]=done&filter_by[]=start_date&filter_by[]=end_date&filter_by[]=due_date&filter_by[]=due_date&filter_value[]=false&filter_value[]=2021-07-14T14:41:15.800Z&filter_value[]=2021-07-21T14:41:15.800Z&filter_value[]=2021-07-21T14:41:15.800Z&filter_value[]=2021-07-14T14:41:15.800Z&filter_comparator[]=equals&filter_comparator[]=greater&filter_comparator[]=less&filter_comparator[]=less&filter_comparator[]=greater&filter_concat=and&filter_include_nulls=true&page=1 12.086587ms - Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0 ``` I seem to have lost all my tasks and the page is empty.

Screenshot 2021-07-14 at 15.43.35.png

118 KiB

konrad commented

2021-07-14 14:51:20 +00:00

What exact steps did you do?

Rustymage commented

2021-07-14 14:56:55 +00:00

I updated to latest. Noticed I was getting 500 errors and then the tasks dissapeared.

I reverted to 0.17.1 and then found the issues above. I'm now back on latest and I have the same issues. I've checked the db and the tasks are present and I'm not getting any log entries showing connection issues to the db.

I updated to `latest`. Noticed I was getting `500` errors and then the tasks dissapeared. I reverted to `0.17.1` and then found the issues above. I'm now back on `latest` and I have the same issues. I've checked the `db` and the tasks are present and I'm not getting any log entries showing connection issues to the `db`.

konrad commented

2021-07-14 16:25:04 +00:00

I updated to latest. Noticed I was getting 500 errors and then the tasks dissapeared.

I mean, what exact steps did you do in the frontend that lead to the error? Something I can use to reproduce it?
Simply browsing try did work without issues and that runs on the latest commit.

You might also want to check that you're running the actual latest version, not just the latest docker image tag. Check if the commit hash from the api version in the about dialoge matches the latest commit from this repo.

Can you enable database logging and send me the output?

Reverting from unstable to a stable version won't really have an effect as the migrations were already executed. The db in that state most likely doesn't match what the api expects. It is only supported to update, not downgrade.

> I updated to latest. Noticed I was getting 500 errors and then the tasks dissapeared. I mean, what exact steps did you do in the frontend that lead to the error? Something I can use to reproduce it? Simply browsing try did work without issues and that runs on the latest commit. You might also want to check that you're running the actual latest version, not just the `latest` docker image tag. Check if the commit hash from the api version in the about dialoge matches the latest commit from this repo. Can you enable database logging and send me the output? Reverting from unstable to a stable version won't really have an effect as the migrations were already executed. The db in that state most likely doesn't match what the api expects. It is only supported to update, not downgrade.

Rustymage commented

2021-07-14 17:18:16 +00:00

I updated to latest. Noticed I was getting 500 errors and then the tasks dissapeared.

I mean, what exact steps did you do in the frontend that lead to the error? Something I can use to reproduce it?
Simply browsing try did work without issues and that runs on the latest commit.

You might also want to check that you're running the actual latest version, not just the latest docker image tag. Check if the commit hash from the api version in the about dialoge matches the latest commit from this repo.

Can you enable database logging and send me the output?

Reverting from unstable to a stable version won't really have an effect as the migrations were already executed. The db in that state most likely doesn't match what the api expects. It is only supported to update, not downgrade.

Good shout on checking version - I deleted all images and pulled the latest ones back down.

Here is my log now:

2021/07/14 17:17:35 Config File "config" Not Found in "[/app/vikunja /etc/vikunja /app/vikunja/.config/vikunja]"
2021/07/14 17:17:35 Using default config.
2021-07-14T17:17:36.016035358Z: WARNING	▶ [DATABASE] 045 Table user_tokens column token db type is TEXT, struct type is VARCHAR(450)
2021-07-14T17:17:36.016494814Z: CRITICAL	▶ migration/Migrate 047 Migration failed: migration 20210711173657 failed: Error 1170: BLOB/TEXT column 'token' used in key specification without a key length

> > I updated to latest. Noticed I was getting 500 errors and then the tasks dissapeared. > > I mean, what exact steps did you do in the frontend that lead to the error? Something I can use to reproduce it? > Simply browsing try did work without issues and that runs on the latest commit. > > You might also want to check that you're running the actual latest version, not just the `latest` docker image tag. Check if the commit hash from the api version in the about dialoge matches the latest commit from this repo. > > Can you enable database logging and send me the output? > > Reverting from unstable to a stable version won't really have an effect as the migrations were already executed. The db in that state most likely doesn't match what the api expects. It is only supported to update, not downgrade. Good shout on checking version - I deleted all images and pulled the latest ones back down. Here is my log now: ``` 2021/07/14 17:17:35 Config File "config" Not Found in "[/app/vikunja /etc/vikunja /app/vikunja/.config/vikunja]" 2021/07/14 17:17:35 Using default config. 2021-07-14T17:17:36.016035358Z: WARNING ▶ [DATABASE] 045 Table user_tokens column token db type is TEXT, struct type is VARCHAR(450) 2021-07-14T17:17:36.016494814Z: CRITICAL ▶ migration/Migrate 047 Migration failed: migration 20210711173657 failed: Error 1170: BLOB/TEXT column 'token' used in key specification without a key length ```

fez commented

2021-07-15 09:00:57 +00:00

Experiencing the same problem. Was running 0.16 on a previous server, just migrated the files to a new server and upgraded vikunja to 0.17.1 when I was at it.
When I try to log in i now get an error Request failed with status code 502

Same log output as @Rustymage as well. Just tried your latest build sha256:20b14845f08941fa6d4650ca718bb60f1bd6c2b44cf021a671c360a7120b474d but getting the same problem and still cant log in.

Current docker-compose file:

version: '3'

services:
  api:
    image: vikunja/api@sha256:20b14845f08941fa6d4650ca718bb60f1bd6c2b44cf021a671c360a7120b474d
    volumes:
      - /home/fez/vikunja:/app/vikunja/files
    restart: unless-stopped
    ports:
      - "3456:3456"
    env_file:
      - /home/fez/vikunja/config.env
  frontend:
    image: vikunja/frontend
    restart: unless-stopped
    ports:
      - "8008:80"

env-file:

VIKUNJA_SERVICE_FRONTENDURL=http://192.168.1.97:8008
VIKUNJA_SERVICE_ENABLEREGISTRATION=false
VIKUNJA_DATABASE_TYPE=mysql
VIKUNJA_DATABASE_USER=vikunja
VIKUNJA_DATABASE_PASSWORD=**redacted**
VIKUNJA_DATABASE_HOST=192.168.1.99:3306
VIKUNJA_DATABASE_DATABASE=vikunja
VIKUNJA_CORS_ORIGINS=https://192.168.1.97:8008,https://192.168.1.97:3456
VIKUNJA_CACHE_ENABLED=false

I just enabled database logging output VIKUNJA_LOG_DATABASE=stdout, but its not showing anything else then what is already in the stdout


2021-07-15T09:00:33.355238936Z: WARNING	▶ [DATABASE] 045 Table user_tokens column token db type is TEXT, struct type is VARCHAR(450)


2021-07-15T09:00:33.355536562Z: CRITICAL	▶ migration/Migrate 047 Migration failed: migration 20210711173657 failed: Error 1170: BLOB/TEXT column 'token' used in key specification without a key length

Experiencing the same problem. Was running 0.16 on a previous server, just migrated the files to a new server and upgraded vikunja to 0.17.1 when I was at it. When I try to log in i now get an error ` Request failed with status code 502 ` Same log output as @Rustymage as well. Just tried your latest build `sha256:20b14845f08941fa6d4650ca718bb60f1bd6c2b44cf021a671c360a7120b474d` but getting the same problem and still cant log in. Current docker-compose file: ``` version: '3' services: api: image: vikunja/api@sha256:20b14845f08941fa6d4650ca718bb60f1bd6c2b44cf021a671c360a7120b474d volumes: - /home/fez/vikunja:/app/vikunja/files restart: unless-stopped ports: - "3456:3456" env_file: - /home/fez/vikunja/config.env frontend: image: vikunja/frontend restart: unless-stopped ports: - "8008:80" ``` env-file: ``` VIKUNJA_SERVICE_FRONTENDURL=http://192.168.1.97:8008 VIKUNJA_SERVICE_ENABLEREGISTRATION=false VIKUNJA_DATABASE_TYPE=mysql VIKUNJA_DATABASE_USER=vikunja VIKUNJA_DATABASE_PASSWORD=**redacted** VIKUNJA_DATABASE_HOST=192.168.1.99:3306 VIKUNJA_DATABASE_DATABASE=vikunja VIKUNJA_CORS_ORIGINS=https://192.168.1.97:8008,https://192.168.1.97:3456 VIKUNJA_CACHE_ENABLED=false ``` I just enabled database logging output `VIKUNJA_LOG_DATABASE=stdout`, but its not showing anything else then what is already in the stdout ``` 2021-07-15T09:00:33.355238936Z: WARNING ▶ [DATABASE] 045 Table user_tokens column token db type is TEXT, struct type is VARCHAR(450) 2021-07-15T09:00:33.355536562Z: CRITICAL ▶ migration/Migrate 047 Migration failed: migration 20210711173657 failed: Error 1170: BLOB/TEXT column 'token' used in key specification without a key length ```

fez commented

2021-07-15 09:28:14 +00:00

Just got it fixed, altering the database manually for user_tokens column token type to VARCHAR(450) from TEXT as mentioned in the error output fixes it.
Looks like the commit is having trouble migrating it on its own? But anyway, manually editing it fixes it.

ALTER TABLE `user_tokens` CHANGE `token` `token` VARCHAR(450) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL;

Just got it fixed, altering the database **manually** for user_tokens column token type to VARCHAR(450) from TEXT as mentioned in the error output fixes it. Looks like the commit is having trouble migrating it on its own? But anyway, manually editing it fixes it. ``` ALTER TABLE `user_tokens` CHANGE `token` `token` VARCHAR(450) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL; ```

konrad commented

2021-07-15 09:38:03 +00:00

That's interesting because it looks like it did create the new table and then tried to modify it in the process. I guess you originally hit the same Error as @Rustymage ("Data too long")?

I've pushed a fix in 4cf7c459da which allows the migration to run again if it failed previously. Please check if it works with that (build is running, should take the usual ~30min).

Was running 0.16 on a previous server, just migrated the files to a new server and upgraded vikunja to 0.17.1 when I was at it.

Again, the latest docker tag contains the status from the main branch. That's unstable, not 0.17.1. If you want to use 0.17.1, use the 0.17.1 tag.

That's interesting because it looks like it did create the new table and then tried to modify it in the process. I guess you originally hit the same Error as @Rustymage ("Data too long")? I've pushed a fix in 4cf7c459da183d1bcce092250f972cd2b52ddca5 which allows the migration to run again if it failed previously. Please check if it works with that ([build is running](https://drone.kolaente.de/vikunja/api/3166), should take the usual ~30min). > Was running 0.16 on a previous server, just migrated the files to a new server and upgraded vikunja to 0.17.1 when I was at it. Again, the `latest` docker tag contains the status from the main branch. That's unstable, not 0.17.1. If you want to use 0.17.1, use the `0.17.1` tag.

fez commented

2021-07-15 09:42:14 +00:00

Sweet and thanks, reverting to 0.17.1 now and manually editing the token back to TEXT to see if the migration happens correctly this time. Reporting back in 30.

Sweet and thanks, reverting to `0.17.1` now and manually editing the token back to TEXT to see if the migration happens correctly this time. Reporting back in 30.

konrad commented

2021-07-15 09:44:47 +00:00

Downgrading back to older versions will probably cause other issues down the road so I wouldn't reccommend doing that.

fez commented

2021-07-15 09:47:33 +00:00

Noted, I fourtunatly made a copy of my database and files before I upgraded so it should be good. :)

Rustymage commented

2021-07-15 10:04:39 +00:00

Noted, I fourtunatly made a copy of my database and files before I upgraded so it should be good. :)

You should be pretty smug then because I didn't :(

> Noted, I fourtunatly made a copy of my database and files before I upgraded so it should be good. :) You should be pretty smug then because I didn't :(

Rustymage commented

2021-07-15 10:06:18 +00:00

That's interesting because it looks like it did create the new table and then tried to modify it in the process. I guess you originally hit the same Error as @Rustymage ("Data too long")?

I've pushed a fix in 4cf7c459da which allows the migration to run again if it failed previously. Please check if it works with that (build is running, should take the usual ~30min).

Was running 0.16 on a previous server, just migrated the files to a new server and upgraded vikunja to 0.17.1 when I was at it.

Again, the latest docker tag contains the status from the main branch. That's unstable, not 0.17.1. If you want to use 0.17.1, use the 0.17.1 tag.

Back up & running!

Thank you both.

Edit: Have a coffee on me 🥇

> That's interesting because it looks like it did create the new table and then tried to modify it in the process. I guess you originally hit the same Error as @Rustymage ("Data too long")? > > I've pushed a fix in 4cf7c459da183d1bcce092250f972cd2b52ddca5 which allows the migration to run again if it failed previously. Please check if it works with that ([build is running](https://drone.kolaente.de/vikunja/api/3166), should take the usual ~30min). > > > Was running 0.16 on a previous server, just migrated the files to a new server and upgraded vikunja to 0.17.1 when I was at it. > > Again, the `latest` docker tag contains the status from the main branch. That's unstable, not 0.17.1. If you want to use 0.17.1, use the `0.17.1` tag. Back up & running! Thank you both. Edit: Have a coffee on me 🥇

👍 1 🎉 2

Rustymage closed this issue

2021-07-15 10:09:33 +00:00

konrad referenced this issue from a commit

2024-02-07 14:00:28 +00:00

fix: loading tasks with infinite scroll in kanban buckets (#920)

Sign in to join this conversation.