[bug] Account Confirmation Email Causes Internal Server Error #999
Labels
No labels
approved, awaiting change
broken setup
bug
cannot reproduce
configuration
documentation
duplicate
enhancement
extremely low priority
feature request
Fix it yourself
help wanted
invalid
mastodon_api
needs change/feedback
needs docs
needs tests
not a bug
not our bug
planned
pleroma_api
privacy
question
static_fe
triage
wontfix
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
AkkomaGang/akkoma#999
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
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?
Your setup
From source
Extra details
Ubuntu 25.04
Version
stable
6d88834f6PostgreSQL version
17
What were you trying to do?
Click the link in email to verify account.
What did you expect to happen?
Confirm account and redirect to main page
What actually happened?
Internal Server Error
Logs
Severity
I cannot use the software
Have you searched for this issue?
the account in this stacktrace is already confirmed - note
is_confirmed: trueandconfirmation_token: nil- not sure if errors on the edge case of trying to confirm a confirmed account are an issue?FloatingGhost, hi thanks for the reply. No. I'm not trying to confirm a confirmed account.
Steps to reproduce:
I tried on the version I created the issue about, I tried it on the latest tag, and the development versions. Each of them gives the same error when you try to confirm a freshly signed up account.
It gives an internal server error in browser, and the stack trace in the backend. Even though it says internal server error, it still does seem to confirm the account.
but your stack trace shows a confirmed account - again, note the is_confirmed field
I can't replicate the issue either
Yes, that's the bug. Account is just freshly created. You receive an activation link. You click the link to activate/confirm account, and it crashes.
I'm definitely not trying to confirm a confirmed account.
There literally is nothing in the code handling this endpoint even attempting to coerce a user into a string:
def confirm_email(conn, %{"user_id" => uid, "token" => token}) docase User.get_cached_by_id(uid) do%User{local: true, is_confirmed: false, confirmation_token: ^token} = user ->case User.confirm(user) do{:ok, _} ->redirect(conn, to: "/"){:error, _} ->json_reply(conn, 400, "Unable to confirm")end%User{is_confirmed: true} ->json_reply(conn, 400, "Already verified email")_ ->json_reply(conn, 400, "Couldn't verify email")endendEither
If anything goes wrong it would need to be during
confirmationitself *(but this too is rather simple code), or during thepost_registration_actionswhich send out emails etc. I cannot reproduce the issue though, neither can FloatingGhost and if the sissue was inpost_registration_actionsmany more instances should be affected. Plus your stacktrace misses the most important bit displaying a puzzlingnofileinstead. As is I’m afraid it’s impossible to help you (and unlikely for it to be a wider issue).To try and restore your setup to a sane state and maybe at least get a proper stacktrace you could try the following to wipe any custom modifications or stale compilation caches; then try again:
Side note: posting password hashes and email addresses for a user as you’ve done in the OP is generally not a good idea; you’ll want to redact those in the future.
After doing your instructions I no longer get an error when trying to verify a new user.
Those are not real hashes or email addresses. I already took care to make sure they were fake when filing the bug.
splendid, seems like either a bugged compile cache and/or some unintentional modification to the source was the culprit then