superseriousbusiness / gotosocial

Fast, fun, small ActivityPub server.
https://docs.gotosocial.org
GNU Affero General Public License v3.0
3.86k stars 338 forks source link

[bug] Data issue #3472

Closed julienXX closed 1 month ago

julienXX commented 1 month ago

Describe the bug with a clear and concise description of what the bug is.

I can't access my profile and notifications. Home timeline is okay.

What's your GoToSocial Version?

v0.17

GoToSocial Arch

x86_64

What happened?

Hello, While migrating from 0.16 to 0.17 one or several migrations have been unfortunately not completed. I first tried to add the missing columns with:

ALTER TABLE statuses ADD COLUMN interaction_policy JSONB;
ALTER TABLE status_faves ADD COLUMN pending_approval BOOLEAN DEFAULT 0;
ALTER TABLE statuses ADD COLUMN approved_by_uri TEXT;
ALTER TABLE statuses ADD COLUMN pending_approval BOOLEAN DEFAULT 0

which wasn't enough. I then attempted to replay the migrations with:

delete from bun_migrations where group_id > 9;

and starting the server again. It's almost okay as I can see my timeline and post toots. One issue though is that regardless of the client I can't go to the notifications or my profile. The errors are: For the profile

Oct 21 13:10:13 nein gotosocial[2771]: timestamp="21/10/2024 13:10:13.924" func=server.init.func1.Logger.13.1 level=ERROR stacktrace="()\n\t/usr/lib/go/src/runtime/panic.go:262\nruntime.sigpanic()\n\t/usr/lib/go/src/runtime/signal_unix.go:900\ntypeutils.placeholderAttachments()\n\t/build/gotosocial/src/gotosocial/internal/typeutils/util.go:177\ntypeutils.(*Converter).statusToAPIStatus()\n\t/build/gotosocial/src/gotosocial/internal/typeutils/internaltofrontend.go:883\n()\n\t/build/gotosocial/src/gotosocial/internal/typeutils/internaltofrontend.go:823\naccount.(*Processor).StatusesGet()\n\t/build/gotosocial/src/gotosocial/internal/processing/account/statuses.go:108\naccounts.(*Module).AccountStatusesGETHandler()\n\t/build/gotosocial/src/gotosocial/internal/api/client/accounts/statuses.go:246\n()\n\t/build/gotosocial/src/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185\ngzip.(*gzipHandler).Handle()\n\t/build/gotosocial/src/pkg/mod/github.com/gin-contrib/gzip@v1.0.1/handler.go:60\n" requestID=jmwwbbmj04001g1fqf40 msg="recovered panic: runtime error: invalid memory address or nil pointer dereference"

For notifications

Oct 21 13:11:08 nein gotosocial[2771]: timestamp="21/10/2024 13:11:08.828" func=server.init.func1.Logger.13.1 level=ERROR stacktrace="()\n\t/usr/lib/go/src/runtime/panic.go:262\nruntime.sigpanic()\n\t/usr/lib/go/src/runtime/signal_unix.go:900\ntypeutils.placeholderAttachments()\n\t/build/gotosocial/src/gotosocial/internal/typeutils/util.go:177\ntypeutils.(*Converter).statusToAPIStatus()\n\t/build/gotosocial/src/gotosocial/internal/typeutils/internaltofrontend.go:883\n()\n\t/build/gotosocial/src/gotosocial/internal/typeutils/internaltofrontend.go:823\ntypeutils.(*Converter).NotificationToAPINotification()\n\t/build/gotosocial/src/gotosocial/internal/typeutils/internaltofrontend.go:1806\ntimeline.(*Processor).NotificationsGet()\n\t/build/gotosocial/src/gotosocial/internal/processing/timeline/notification.go:107\nnotifications.(*Module).NotificationsGETHandler()\n\t/build/gotosocial/src/gotosocial/internal/api/client/notifications/notificationsget.go:167\n()\n\t/build/gotosocial/src/pkg/mod/github.com/gin-gonic/gin@v1.10.0/context.go:185\n" requestID=348cdbmj04000x52tj90 msg="recovered panic: runtime error: invalid memory address or nil pointer dereference"

Both errors seem to happen in the placeholderAttachment function, probably because of a data issue but I can't pinpoint it. If anybody is able to point me in the right direction that would be great!

What you expected to happen?

No response

How to reproduce it?

No response

Anything else we need to know?

No response

tsmethurst commented 1 month ago

Hiya, if migrations failed your best bet is to roll back to your database backup and try them again; manually editing the migrations table to force remigration is not a good idea, as we don't guarantee idempotency of migrations (even though many of them are in practice idempotent, not all of them are).

If you didn't back up your db, or you've lost your backup, you can also try running the migrations manually using the commands in this gist -- https://gist.github.com/tsmethurst/f243cf59884cf893dfc138b600a54115 -- but there's no guarantee that'll work.

tsmethurst commented 1 month ago

In any case I'll close this as it's not really a bug :P

julienXX commented 1 month ago

Thanks! Sorry for miscategorizing my issue, I tried to run all the migrations but it's still failing. I'll keep digging to find which status is causing the panic.

tsmethurst commented 1 month ago

Hmm it looks like it's something to do with the field RemoteURL not being set; at least, that's what the nil pointer dereference is about. So it's this command that's most important I think:

UPDATE "media_attachments" SET "url" = '', "file_path" = '', "file_content_type" = '', "file_file_size" = 0, "thumbnail_path" = '', "thumbnail_content_type" = '', "thumbnail_file_size" = 0, "thumbnail_url" = '' WHERE ("type" = 0);

You might be able to rescue this as a last resort with the following command but I'm not sure what kind of state it will leave you in, so use it at your own risk:

DELETE FROM media_attachments WHERE (url = '' OR url IS NULL) AND (remote_url='' OR remote_url IS NULL);