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

[GH-ISSUE #420] Critical error: invalid character 'd' looking for beginning of value #6157

New Issue
Closed
opened 2026-04-20 16:45:53 -05:00 by GiteaMirror · 11 comments
GiteaMirror commented 2026-04-20 16:45:53 -05:00
Owner
Copy Link

Originally created by @KhaaL on GitHub (Mar 13, 2025).
Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/420

I have a user that was created over OICD through a Keycloak instance, which causes an error when I try to delete it.

Attempts at deletion

I've tried deleting the user from the Vikunja web-interface, but after passing the 3-day deadline, the warning banner will change is warning to a date in the past:
`We will delete your Vikunja account at ... (yesterday). To cancel the deletion of your account, click here.

I've tried deleting the user from the CLI, but i get the following error:

$ sudo docker exec -it vikunja /app/vikunja/vikunja user delete 4 -n
2025-03-06T20:47:02+01:00: INFO ▶ 001 Using config file: /etc/vikunja/config.yml
2025-03-06T20:47:02+01:00: INFO ▶ 002 Running migrations…
2025-03-06T20:47:02+01:00: INFO ▶ 06d Ran all migrations successfully.
You requested to delete the user immediately. Are you sure?
To confirm, please type "yes, I confirm" in all uppercase:
YES, I CONFIRM
2025-03-06T20:47:07+01:00: CRITICAL     ▶ 0f6 Error removing the user: invalid character 'd' looking for beginning of value
exit status 1

Errors on exporting tasks

Exporting a task causes an error when looking through the logs:

2025-03-13T06:45:34+01:00: DEBUG        ▶ 257c7 Starting to export user data for user 4...
2025-03-13T06:45:34+01:00: ERROR        ▶ 257d5 Error while handling message 2423274c-29ef-42e7-bb79-11749b88c11b, handler_poisoned=user.export.requested.handle.user.data.export, subscriber_poisoned=gochannel.GoChannel, reason_poisoned=invalid character 'd' looking for beginning of value, topic_poisoned=user.export.requested,  payload={"user":{"id":4,"name":"khaal","username":"formally-allowing-sunfish","created":"2025-02-27T20:07:40Z","updated":"2025-03-13T05:38:00Z"}}

Each file subsequently created in /files/user-export-tmp is 4 kb small.

Exporting data with other, local auth users, works as intended.

Error on login

When the user logs in through keycloak, an error is shown in vikunja logs and on the client respectively, however the user is able to complete the login flow.

Vikunja log:

vikunja      | 2025-03-11T11:50:24+01:00: ERROR ▶ fe0 invalid character 'd' looking for beginning of value

For what its worth, here's the JSON of the user: from the /api/v1/user endpoint:

{"id":4,"name":"khaal","username":"formally-allowing-sunfish","created":"2025-02-27T20:07:40Z","updated":"2025-03-11T10:23:34Z","settings":{"name":"khaal","email_reminders_enabled":false,"discoverable_by_name":false,"discoverable_by_email":false,"overdue_tasks_reminders_enabled":false,"overdue_tasks_reminders_time":"9:00","default_project_id":7,"week_start":1,"language":"en","timezone":"Europe/Stockholm","frontend_settings":{"color_schema":"auto","default_view":"first","play_sound_when_done":false,"quick_add_magic_mode":"vikunja"}},"deletion_scheduled_at":"0001-01-01T00:00:00Z","is_local_user":false,"auth_provider":"keycloak_instance"}

I'm running Vikunja Version: v0.24.1-873-ff53084e93 as a docker image, on SQLite

Originally created by @KhaaL on GitHub (Mar 13, 2025). Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/420 I have a user that was created over OICD through a Keycloak instance, which causes an error when I try to delete it. ## Attempts at deletion I've tried deleting the user from the Vikunja web-interface, but after passing the 3-day deadline, the warning banner will change is warning to a date in the past: `We will delete your Vikunja account at ... (yesterday). To cancel the deletion of your account, click here. I've tried deleting the user from the CLI, but i get the following error: ```sh $ sudo docker exec -it vikunja /app/vikunja/vikunja user delete 4 -n 2025-03-06T20:47:02+01:00: INFO ▶ 001 Using config file: /etc/vikunja/config.yml 2025-03-06T20:47:02+01:00: INFO ▶ 002 Running migrations… 2025-03-06T20:47:02+01:00: INFO ▶ 06d Ran all migrations successfully. You requested to delete the user immediately. Are you sure? To confirm, please type "yes, I confirm" in all uppercase: YES, I CONFIRM 2025-03-06T20:47:07+01:00: CRITICAL ▶ 0f6 Error removing the user: invalid character 'd' looking for beginning of value exit status 1 ``` ## Errors on exporting tasks Exporting a task causes an error when looking through the logs: ``` 2025-03-13T06:45:34+01:00: DEBUG ▶ 257c7 Starting to export user data for user 4... 2025-03-13T06:45:34+01:00: ERROR ▶ 257d5 Error while handling message 2423274c-29ef-42e7-bb79-11749b88c11b, handler_poisoned=user.export.requested.handle.user.data.export, subscriber_poisoned=gochannel.GoChannel, reason_poisoned=invalid character 'd' looking for beginning of value, topic_poisoned=user.export.requested, payload={"user":{"id":4,"name":"khaal","username":"formally-allowing-sunfish","created":"2025-02-27T20:07:40Z","updated":"2025-03-13T05:38:00Z"}} ``` Each file subsequently created in `/files/user-export-tmp` is 4 kb small. Exporting data with other, local auth users, works as intended. ## Error on login When the user logs in through keycloak, an error is shown in vikunja logs and on the client respectively, however the user is able to complete the login flow. Vikunja log: ``` vikunja | 2025-03-11T11:50:24+01:00: ERROR ▶ fe0 invalid character 'd' looking for beginning of value ``` For what its worth, here's the JSON of the user: from the `/api/v1/user` endpoint: ```json {"id":4,"name":"khaal","username":"formally-allowing-sunfish","created":"2025-02-27T20:07:40Z","updated":"2025-03-11T10:23:34Z","settings":{"name":"khaal","email_reminders_enabled":false,"discoverable_by_name":false,"discoverable_by_email":false,"overdue_tasks_reminders_enabled":false,"overdue_tasks_reminders_time":"9:00","default_project_id":7,"week_start":1,"language":"en","timezone":"Europe/Stockholm","frontend_settings":{"color_schema":"auto","default_view":"first","play_sound_when_done":false,"quick_add_magic_mode":"vikunja"}},"deletion_scheduled_at":"0001-01-01T00:00:00Z","is_local_user":false,"auth_provider":"keycloak_instance"} ``` I'm running Vikunja Version: v0.24.1-873-ff53084e93 as a docker image, on SQLite
GiteaMirror commented 2026-04-20 16:45:55 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Mar 19, 2025):

I'm unable to reproduce this. Is that user specific?

<!-- gh-comment-id:2737049693 --> @kolaente commented on GitHub (Mar 19, 2025): I'm unable to reproduce this. Is that user specific?
GiteaMirror commented 2026-04-20 16:45:55 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Mar 19, 2025):

Does it work if you disable the user first?

(Note to self: This might be related to json parsing, which will only happen when async sending a notification)

<!-- gh-comment-id:2737053866 --> @kolaente commented on GitHub (Mar 19, 2025): Does it work if you disable the user first? (Note to self: This might be related to json parsing, which will only happen when async sending a notification)
GiteaMirror commented 2026-04-20 16:45:56 -05:00
Author
Owner
Copy Link

@KhaaL commented on GitHub (Mar 22, 2025):

No, disabling the user dosen't work and this only happens on this user that was created with OICD.

If possible, I'd love a remidiation suggestion and, if you have any theories on what this might be caused about so I can try to reproduce it. I don't remember all the steps that took me here 😅

<!-- gh-comment-id:2745164748 --> @KhaaL commented on GitHub (Mar 22, 2025): No, disabling the user dosen't work and this only happens on this user that was created with OICD. If possible, I'd love a remidiation suggestion and, if you have any theories on what this might be caused about so I can try to reproduce it. I don't remember all the steps that took me here 😅
GiteaMirror commented 2026-04-20 16:45:57 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Mar 22, 2025):

Does it yield the same error message when you try to disable the user?

The problem is I'm unable to reproduce it, that makes it hard to find a remediation.

<!-- gh-comment-id:2745198363 --> @kolaente commented on GitHub (Mar 22, 2025): Does it yield the same error message when you try to disable the user? The problem is I'm unable to reproduce it, that makes it hard to find a remediation.
GiteaMirror commented 2026-04-20 16:45:58 -05:00
Author
Owner
Copy Link

@KhaaL commented on GitHub (Mar 23, 2025):

Disabling the affected user works without any error message, but that affected user cannot be deleted. I put some time to do some testing and did some direct changed to the sqlite database.

Deleting the rows in the Projects table where owner_id = affected userID resulted in the affected user could be deleted with the -n flag.

However, when I copied over the database file before I made all these changes to my local machine while running the 0.24.6 binary, I could delete the user with the -n flag without any modifications to the database file.

So this seems to be a bug with the unstable build (v0.24.1-873-ff53084e93) rather than an issue with the data in the database.

@kolaente If you want any more details from me or a dump of the database, let me know 🙂

<!-- gh-comment-id:2746361145 --> @KhaaL commented on GitHub (Mar 23, 2025): Disabling the affected user works without any error message, but that affected user cannot be deleted. I put some time to do some testing and did some direct changed to the sqlite database. Deleting the rows in the Projects table where `owner_id` = affected userID resulted in the affected user could be deleted with the -n flag. However, when I copied over the database file _before_ I made all these changes to my local machine while running the 0.24.6 binary, I could delete the user with the -n flag without any modifications to the database file. So this seems to be a bug with the unstable build (v0.24.1-873-ff53084e93) rather than an issue with the data in the database. @kolaente If you want any more details from me or a dump of the database, let me know 🙂
GiteaMirror commented 2026-04-20 16:45:59 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Mar 23, 2025):

Disabling the affected user works without any error message, but that affected user cannot be deleted.

Just to clarify, if you disable the user and then try to delete it, you still get the mentioned error?

If you want any more details from me or a dump of the database, let me know 🙂

A database dump would actually be amazing to reproduce this! You can also send it to me privately at konrad@vikunja.io

<!-- gh-comment-id:2746388384 --> @kolaente commented on GitHub (Mar 23, 2025): > Disabling the affected user works without any error message, but that affected user cannot be deleted. Just to clarify, if you disable the user and then try to delete it, you still get the mentioned error? > If you want any more details from me or a dump of the database, let me know 🙂 A database dump would actually be amazing to reproduce this! You can also send it to me privately at konrad@vikunja.io
GiteaMirror commented 2026-04-20 16:45:59 -05:00
Author
Owner
Copy Link

@KhaaL commented on GitHub (Mar 23, 2025):

Just to clarify, if you disable the user and then try to delete it, you still get the mentioned error?

Yes

A database dump would actually be amazing to reproduce this!

You got mail 🙂

<!-- gh-comment-id:2746392470 --> @KhaaL commented on GitHub (Mar 23, 2025): > Just to clarify, if you disable the user and then try to delete it, you still get the mentioned error? Yes > A database dump would actually be amazing to reproduce this! _You got mail_ 🙂
GiteaMirror commented 2026-04-20 16:46:00 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Mar 23, 2025):

The dump really helped! It seems like a previous migration from the old filter format in project views didn't go as planned. I've added another migration to make it work again.

This should be fixed now in 62b2c6771a, please check with the next unstable build (should be ready for deployment in ~45min.

<!-- gh-comment-id:2746413575 --> @kolaente commented on GitHub (Mar 23, 2025): The dump really helped! It seems like a previous migration from the old filter format in project views didn't go as planned. I've added another migration to make it work again. This should be fixed now in https://github.com/go-vikunja/vikunja/commit/62b2c6771a744555e9ebe829361e2dff008cffff, please check with the next unstable build (should be ready for deployment in ~45min.
GiteaMirror commented 2026-04-20 16:46:02 -05:00
Author
Owner
Copy Link

@chrismilson commented on GitHub (Aug 31, 2025):

Is there a way to trigger the migration specificed in 62b2c67?

<!-- gh-comment-id:3240412709 --> @chrismilson commented on GitHub (Aug 31, 2025): Is there a way to trigger the migration specificed in 62b2c67?
GiteaMirror commented 2026-04-20 16:46:03 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Aug 31, 2025):

It should've run automatically on startup. If it put the entry for the migration (the filename) in the migrations table, you can remove the entry from the table and restart Vikunja. That should trigger it again.

<!-- gh-comment-id:3240430174 --> @kolaente commented on GitHub (Aug 31, 2025): It should've run automatically on startup. If it put the entry for the migration (the filename) in the `migrations` table, you can remove the entry from the table and restart Vikunja. That should trigger it again.
GiteaMirror commented 2026-04-20 16:46:04 -05:00
Author
Owner
Copy Link

@chrismilson commented on GitHub (Aug 31, 2025):

Yep, the migration id was already in the migration table. Removing it (with DELETE FROM migration WHERE id = '20250323212553') and restarting vikunja successfully updated the project_views table.

<!-- gh-comment-id:3240438419 --> @chrismilson commented on GitHub (Aug 31, 2025): Yep, the migration id was already in the `migration` table. Removing it (with `DELETE FROM migration WHERE id = '20250323212553'`) and restarting vikunja successfully updated the `project_views` table.
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#6157
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?