github-starred/vikunja
2
0
Fork 0
mirror of https://github.com/go-vikunja/vikunja.git synced 2026-05-08 12:57:52 -05:00
Code Issues 690 Packages Projects Releases 11 Wiki Activity

[GH-ISSUE #2431] Migration 20260224215050 error when upgrading to 2.2.0 from 1.1.0 #6670

New Issue
Closed
opened 2026-04-20 17:15:37 -05:00 by GiteaMirror · 4 comments
GiteaMirror commented 2026-04-20 17:15:37 -05:00
Owner
Copy Link

Originally created by @damienalexandre on GitHub (Mar 20, 2026).
Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/2431

Pre-submission checklist

  • I have searched for existing open or closed issue reports with the same problem.

Description

I run Vikunja on Docker, with MySQL 8.0.22-13.

I upgraded from 1.1.0 to 2.2.0 and got this error:

2026-03-20T15:31:46.111Z: time=2026-03-20T15:31:46.109Z level=INFO msg="No config file found, using default or config from environment variables."
2026-03-20T15:31:46.518Z: time=2026-03-20T15:31:46.517Z level=INFO msg="Running migrations…"
2026-03-20T15:31:48.586Z: time=2026-03-20T15:31:48.586Z level=ERROR msg="Migration failed: migration 20260224215050 failed: Error 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'IF NOT EXISTS IDX_webhooks_user_id ON webhooks (user_id)' at line 1"

How can I fix / debug this?

Vikunja Version

1.1.0

Browser and version

No response

Can you reproduce the bug on the Vikunja demo site?

No

Screenshots

No response

Originally created by @damienalexandre on GitHub (Mar 20, 2026). Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/2431 ### Pre-submission checklist - [x] I have searched for existing open or closed issue reports with the same problem. ### Description I run Vikunja on Docker, with MySQL 8.0.22-13. I upgraded from 1.1.0 to 2.2.0 and got this error: > 2026-03-20T15:31:46.111Z: time=2026-03-20T15:31:46.109Z level=INFO msg="No config file found, using default or config from environment variables." > 2026-03-20T15:31:46.518Z: time=2026-03-20T15:31:46.517Z level=INFO msg="Running migrations…" > 2026-03-20T15:31:48.586Z: time=2026-03-20T15:31:48.586Z level=ERROR msg="**Migration failed: migration 20260224215050 failed: Error 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'IF NOT EXISTS IDX_webhooks_user_id ON webhooks (user_id)' at line 1**" How can I fix / debug this? ### Vikunja Version 1.1.0 ### Browser and version _No response_ ### Can you reproduce the bug on the Vikunja demo site? No ### Screenshots _No response_
GiteaMirror commented 2026-04-20 17:15:38 -05:00
Author
Owner
Copy Link

@Anduin2017 commented on GitHub (Mar 21, 2026):

Same here.

The Vikunja app container fails to start and enters a crash loop during the database migration phase. The migration 20260224215050 attempts to create an index using the IF NOT EXISTS syntax, which is not supported in standard MySQL (tested on version 9.6.0), resulting in a SQL syntax error (Error 1064).

Environment Info

  • Vikunja Version: v2.2.0
  • Container Image: pubhub.aiursoft.com/vikunja/vikunja:latest (Digest: sha256:fefda8ba71c3b06cc7f53f93ee14ebf1ad155a535e572b8dc702a46d789fc6d1)
  • Database: MySQL 9.6.0 (Community Server)
  • Deployment: Docker Swarm / Docker Compose

Log Output

time=2026-03-21T08:55:29.418Z level=INFO msg="Using config file: /app/vikunja/config.yml"
time=2026-03-21T08:55:29.418Z level=INFO msg="Running migrations…"
time=2026-03-21T08:55:29.445Z level=ERROR msg="Migration failed: migration 20260224215050 failed: Error 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'IF NOT EXISTS IDX_webhooks_user_id ON webhooks (user_id)' at line 1"

Investigation Conclusions

The error is caused by the following SQL statement executed during migration 20260224215050:

CREATE INDEX IF NOT EXISTS IDX_webhooks_user_id ON webhooks (user_id);

While CREATE INDEX IF NOT EXISTS is valid in MariaDB (since 10.5.2), it is not valid syntax in standard MySQL. MySQL requires either a plain CREATE INDEX (which fails if it exists) or a procedure to check for existence before creation.

Suggestion for Fix

The migration should be updated to use a more compatible approach for MySQL, such as checking if the index exists via INFORMATION_SCHEMA.STATISTICS or using a migration framework that abstracts index creation across different database types.

Mitigation for Affected Users (Manual Fix)

If you are stuck in a crash loop, you can manually apply the migration by following these steps:

  1. Log into your MySQL instance.
  2. Select the vikunja database.
  3. Run the following SQL to manually create the index and mark the migration as completed:
-- 1. Manually create the missing index (This is where the syntax error occurs)
CREATE INDEX IDX_webhooks_user_id ON webhooks (user_id);

-- 2. Manually execute the next step in the migration which was skipped
ALTER TABLE webhooks MODIFY COLUMN project_id bigint NULL;

-- 3. Mark the migration as finished to skip it on next boot
INSERT INTO migration (id) VALUES ('20260224215050');
  1. Restart your Vikunja app container. It should now skip the failing migration and start successfully.
<!-- gh-comment-id:4102901344 --> @Anduin2017 commented on GitHub (Mar 21, 2026): Same here. The Vikunja app container fails to start and enters a crash loop during the database migration phase. The migration `20260224215050` attempts to create an index using the `IF NOT EXISTS` syntax, which is not supported in standard MySQL (tested on version 9.6.0), resulting in a SQL syntax error (Error 1064). ## Environment Info - **Vikunja Version:** v2.2.0 - **Container Image:** `pubhub.aiursoft.com/vikunja/vikunja:latest` (Digest: `sha256:fefda8ba71c3b06cc7f53f93ee14ebf1ad155a535e572b8dc702a46d789fc6d1`) - **Database:** MySQL 9.6.0 (Community Server) - **Deployment:** Docker Swarm / Docker Compose ## Log Output ```text time=2026-03-21T08:55:29.418Z level=INFO msg="Using config file: /app/vikunja/config.yml" time=2026-03-21T08:55:29.418Z level=INFO msg="Running migrations…" time=2026-03-21T08:55:29.445Z level=ERROR msg="Migration failed: migration 20260224215050 failed: Error 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'IF NOT EXISTS IDX_webhooks_user_id ON webhooks (user_id)' at line 1" ``` ## Investigation Conclusions The error is caused by the following SQL statement executed during migration `20260224215050`: ```sql CREATE INDEX IF NOT EXISTS IDX_webhooks_user_id ON webhooks (user_id); ``` While `CREATE INDEX IF NOT EXISTS` is valid in MariaDB (since 10.5.2), it is **not valid syntax** in standard MySQL. MySQL requires either a plain `CREATE INDEX` (which fails if it exists) or a procedure to check for existence before creation. ## Suggestion for Fix The migration should be updated to use a more compatible approach for MySQL, such as checking if the index exists via `INFORMATION_SCHEMA.STATISTICS` or using a migration framework that abstracts index creation across different database types. ## Mitigation for Affected Users (Manual Fix) If you are stuck in a crash loop, you can manually apply the migration by following these steps: 1. Log into your MySQL instance. 2. Select the `vikunja` database. 3. Run the following SQL to manually create the index and mark the migration as completed: ```sql -- 1. Manually create the missing index (This is where the syntax error occurs) CREATE INDEX IDX_webhooks_user_id ON webhooks (user_id); -- 2. Manually execute the next step in the migration which was skipped ALTER TABLE webhooks MODIFY COLUMN project_id bigint NULL; -- 3. Mark the migration as finished to skip it on next boot INSERT INTO migration (id) VALUES ('20260224215050'); ``` 4. Restart your Vikunja app container. It should now skip the failing migration and start successfully.
GiteaMirror commented 2026-04-20 17:15:39 -05:00
Author
Owner
Copy Link

@codersaur commented on GitHub (Mar 21, 2026):

-- 1. Manually create the missing index (This is where the syntax error occurs)
CREATE INDEX IDX_webhooks_user_id ON webhooks (user_id);

-- 2. Manually execute the next step in the migration which was skipped
ALTER TABLE webhooks MODIFY COLUMN project_id bigint NULL;

-- 3. Mark the migration as finished to skip it on next boot
INSERT INTO migration (id) VALUES ('20260224215050');

Same issue here. The manual fix worked for me though.

<!-- gh-comment-id:4104398603 --> @codersaur commented on GitHub (Mar 21, 2026): > -- 1. Manually create the missing index (This is where the syntax error occurs) > CREATE INDEX IDX_webhooks_user_id ON webhooks (user_id); > > -- 2. Manually execute the next step in the migration which was skipped > ALTER TABLE webhooks MODIFY COLUMN project_id bigint NULL; > > -- 3. Mark the migration as finished to skip it on next boot > INSERT INTO migration (id) VALUES ('20260224215050'); Same issue here. The manual fix worked for me though.
GiteaMirror commented 2026-04-20 17:15:39 -05:00
Author
Owner
Copy Link

@leonanu commented on GitHub (Mar 22, 2026):

-- 1. Manually create the missing index (This is where the syntax error occurs)
CREATE INDEX IDX_webhooks_user_id ON webhooks (user_id);
-- 2. Manually execute the next step in the migration which was skipped
ALTER TABLE webhooks MODIFY COLUMN project_id bigint NULL;
-- 3. Mark the migration as finished to skip it on next boot
INSERT INTO migration (id) VALUES ('20260224215050');

Same issue here. The manual fix worked for me though.

Yes. Thank you!

<!-- gh-comment-id:4106190656 --> @leonanu commented on GitHub (Mar 22, 2026): > > -- 1. Manually create the missing index (This is where the syntax error occurs) > > CREATE INDEX IDX_webhooks_user_id ON webhooks (user_id); > > -- 2. Manually execute the next step in the migration which was skipped > > ALTER TABLE webhooks MODIFY COLUMN project_id bigint NULL; > > -- 3. Mark the migration as finished to skip it on next boot > > INSERT INTO migration (id) VALUES ('20260224215050'); > > Same issue here. The manual fix worked for me though. Yes. Thank you!
GiteaMirror commented 2026-04-20 17:15:40 -05:00
Author
Owner
Copy Link

@vikunja-bot-app[bot] commented on GitHub (Mar 23, 2026):

This issue has been fixed in #2455, please check with the next unstable build (should be ready for deployment in ~30min, also on the demo).

<!-- gh-comment-id:4112310239 --> @vikunja-bot-app[bot] commented on GitHub (Mar 23, 2026): This issue has been fixed in #2455, please check with the next unstable build (should be ready for deployment in ~30min, also on [the demo](https://try.vikunja.io)).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
area/attachments
area/auth
area/avatars
area/backup-restore
area/caldav
area/calendar-view
area/comments
area/config
area/database
area/desktop
area/docker
area/email
area/favorites
area/filters
area/frontend
area/gantt
area/i18n
area/import-export
area/internal-code
area/kanban
area/labels
area/list-view
area/mobile
area/notifications
area/permissions
area/projects
area/pwa
area/recurring-tasks
area/reminders
area/search
area/shortcuts
area/subtasks
area/sync
area/table-view
area/task-editor
area/task-metadata
area/task-relations
area/teams
area/theming
area/time-tracking
area/typesense
area/views
area/webhooks
bug
changes requested
concern/accessibility
concern/performance
concern/regression
concern/ux
confirmed
db/mysql
dependencies
enhancement
good first issue
help wanted
integration/inbound
integration/outbound
kind/bug
kind/feature
needs reproduction
pull-request
Mirrored from GitHub Pull Request
 question
security
support
upstream issue
waiting for reply
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vikunja#6670
Delete Branch "%!s()"

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?