Vikunja updated, no longer able to log in - "Migration failed," "Error 1406" in API container

Hi,

My server runs Watchtower once weekly. After whatever the most recent update was for the official Vikunja frontend, API, and MariaDB 10 containers, I can no longer log in with status code 405. I tried clearing cache and using a different browser to no avail.

Then I looked at the logs for all of the containers. Nothing abnormal on the frontend, of course. Then I see this error in the API container logs, over and over and over…

2021-07-24T20:51:15.01680178Z: CRITICAL	▶ migration/Migrate 047 Migration failed: migration 20210711173657 failed: Error 1406: Data too long for column 'token' at row 1

Additionally, I’m getting this repeatedly from MariaDB:

2021-07-24 20:52:15 14 [Warning] Aborted connection 14 to db: 'vikunja' user: 'vikunja' host: '172.23.0.3' (Got an error reading communication packets)

Are these things related? What can I do? I have so much stuff in Vikunja that, if I had to start from scratch, I would have to move to a more provably stable platform.

Additional info:
OS: CentOS 8 stable
Docker version: 20.10.7
Vikunja frontend/API version: Whatever the latest tag is for both, it was last updated on Wednesday morning if there have been any updates since then

I’m guessing you’re hitting this: #920 - Error Request failed with status code 500 Internal Server Error - api - Gitea

What’s the api version you get with vikunja version in the container?

Using the latest tag puts you on whatever is on the main branch at that moment. Those may contain bugs because they are, well, unstable. If you only want the stable versions you should pin the image in the compose file to that of a stable version.

I might change that with the next release though. And I should put a note in the docs I suppose.

Oh wow. I had no idea that the latest tag was dev. That’s rather odd for 99% of projects, I’ll admit, so I wasn’t expecting that. Others usually specify a develop branch or similar.

Now that I’ve had time to stop and think, I might just restore a backup of the DB file and revert the images to the last stable version. And then pray.

I’ll update this post with the API version.

I couldn’t get the API version, as the container was constantly restarting itself. Like I said, it’s whatever the latest was as of Wednesday.

Anyway, I tried reverting back to 0.17 but that didn’t work. I guess there’s already been new features added since then so the db is incompatible; at least that’s what the logs are telling me. Is there any way to find the dev release prior to the one that broke my instance? I’ll stick around on that one until the next stable release and disable Watchtower on those containers.

I manually deleted and forced redownload of the latest containers. It seems to have worked after a browser cache refresh. I am going to grab the hash of this version so no further updates are done until the next stable release is out.

1 Like

Yeah I’m definitely changing this with the next release. My personal instance runs on latest as well but I don’t have a watchtower for that and update it manually every few days or so.