[unstable version] reason_poisoned=pq: relation "webhooks" does not exist #1655
Labels
No Label
dependencies
duplicate
help wanted
invalid
kind/bug
kind/feature
needs reproduction
question
security
wontfix
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: vikunja/vikunja#1655
Loading…
Reference in New Issue
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?
Description
When importing data from 0.21.0 to the latest unstable, I get the following errors:
I'm not sure if you are expecting to support Vikunja exports/imports across versions, or if that's out of scope.
Vikunja Frontend Version
Frontend Version: 0.21.0+368-282ec3164b
Vikunja API Version
API Version: v0.21.0+214-f26f1326ea
Browser and version
No response
Can you reproduce the bug on the Vikunja demo site?
No
Screenshots
No response
Importing across versions is not explicitly supported but it might still work.
It looks like you tried to import a dump generated by the
vikunja dumpcli command via the web ui? That won't work in any case. Usevikunja restorefor that.I utilized the web UI to generate the Vikunja export (old instance):
Which I then tried to import to the new Vikunja instance.
I will give the
vikunja restorecommand a shot though...Using the CLI will replace the whole instance - and doesn't really support migration across versions either.
What's interesting about this is the error - it actually seems unrelated to the import. Does the same error happen if you create a new task?
Oh, I hadn't even seen that webhooks were added yet, I should've looked the error some more lol. It seems to return an error when projects that existed even prior to the import, have their webhooks "edited":
It returns the following error:
Creating a new task doesn't seem to lead to any errors...
Looks like the migration which should've created the webhooks table didn't run (I think we've seen this before). Can you check in the
migrationstable if the 20230913202615 migration has been run?So it doesn't look like
20230913202615was created/run then...This was just a "fresh" Vikunja running the latest unstable api/frontend, with a completely empty DB. So I'm assuming that the migration should have been run?
I feel like a broken record always coming to you with:
"Hey brand new setups are broken w/ Postgres because of " 😅
I'm not sure if I'm just cursed or if it's just me lol
But it is included in the list of your screenshot? The
migration_statustable seems to have been modified correctly as per20231108231513. Maybe this happens only with new tables?Does it work if you remove the entry from
20230913202615and restart the api?That's exactly the thing. All pending migrations are applied on start of the api automatically. Even if the api or the datasbase crashes mid-way while running a migration, it should be picked up next time the api is restarted.
Doesn't seem to be related to postgres either from what I could check on the instances I run.
I should've just done a
SELECTstatement then looking at it via my eyeballs, yep, that migration is there then.I'm assuming that the
relation "webhooks" does not existerror is because of the20230913202615not executing? I'll go ahead and try with removing that entry in the table, and restarting the API container...Well perhaps it would be easier to replicate if I lay out what I was trying to accomplish:
That's how I was able to get the above error...
The only nuance that I can see is that I had a subtask of a task, that was imported into one of the newly imported projects. It seemed to create this weird infinite loop, and perhaps that's what broke the import?
Are you importing with the cli commands? Because that runs all migrations, maybe there's something wrong there.
No, I'm using the web UI :)
Well, with the
migrationtable looking like this:I'm at least able to get further during an import, but still get the following error...
Let me know if you just want me to send you my export as well!
Importing via the web UI won't run any migrations or change anything else with the table structure. I don't think this is related to that (other than the error with the missing table becoming visible). Especially since we've seen this before, I think it was the Typesense sync table back then?
Did removing the migration entry and restarting the api create the table as expected?
I removed the
20230913202615from themigrationstable, and then restarted the API container. It then created the new entry as expected:I can try completely removing the
migrationstable if you would like me to try?Yes, I believe that it was due to the index not being created within Typesense before (maybe they were unrelated to one another and were two separate issues?)
Did it create the webhooks table?
Oh, no it did not! In the screenshot here (vikunja/api#1655 (comment)), these are all the tables in the DB.
Was there anything in the logs when you restarted it to re-run the migration?
I restarted the pod a few more times to add the
DEBUGvalues to get more interesting output:Then it...finally added the webhooks table?:
Let me try to access the webhooks from the UI now....
yep, and I'm able to access the UI now too:
Looking through my logs, I don't see anything to indicate that anything weird/bad happened when trying to create the table? In order of oldest logs to new, for anything related to
migration:Perhaps, when the Vikunja database is first being created and there isn't a Typesense index, the migration isn't successful? Not sure if the two are related...
The Typesense index is independent of the rest (at least it should be).
Glad it works for you now, but "restart the pod a few times until it works" isn't really a solution. Not sure what to do about it though. First step would be to have it reproducible.
If I'm lucky enough to reproduce it, I'll be sure to reopen the issue :)
You can close it if you would like @konrad!
Thank you very much already for the report and your patience!
@konrad what's the easiest environment to pass around do you think, is a Docker Compose the easiest thing to provide you to more easily reproduce issues?
Yeah docker compose should work.
@konrad one last thing to bother you - I accidentally pushed a container (a "package" as Gitea calls it) to this Gitea. I'm not sure if you meant to have that enabled or not since you have disabled allowing other users to create repositories. Gitea config docs on it are here if you wish to disable it for other users. :)
Thanks for the hint, should be disabled now. Can you check again?
It's interesting, I'm able to push container layers (therefore taking up space "maliciously" on your Gitea), but it still returns a
403:Here's what it returns:
I wonder if you then have to enable the
CLEANUP_PACKAGEScronjob then incase someone else does this? You can delete my comments, so that others can't see that it's even possible to push layers...https://github.com/go-gitea/gitea/issues/20631
I reproducible have this issue with the setup I described on GH here https://github.com/go-vikunja/api/issues/104. I am just commenting here for clarity. Brand new setup, no migration. Currently unable to resolve.
Looks like the table was not created when starting from scratch, only when upgrading from a previous version. Hence I didn't see this error with any of my own installations.
Should be fixed in
09696aec1b. Please check with the next unstable build.