503 Error Occurs on User Profile Page

sevichecc · 20 August 2023 10:33

On the kongwoo.icu website, when I visit a user profile page using the default route of /users/:userid, I receive a 503 error. However, when I try visiting the page using the /:userid route instead, everything works correctly. I’m unsure what may be causing the 503 error when using the /user/:userid route.

Success: Akkoma
Failed: https://kongwoo.icu/users/seviche

The Error Log:

 request_id=F30QWpiQSzpuQt8AB4gi
 [error] Internal server error: %CaseClauseError{term: {:ok, {{~c"HTTP/1.1", 403, ~c"Forbidden"}, [{~c"cache-control", ~c"private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0"}, {~c"connection", ~c"close"}, {~c"date", ~c"Sun, 20 Aug 2023 10:23:36 GMT"}, {~c"server", ~c"cloudflare"}, {~c"content-length", ~c"5602"}, {~c"content-type", ~c"text/html; charset=UTF-8"}, {~c"expires", ~c"Thu, 01 Jan 1970 00:00:01 GMT"}, {~c"cross-origin-embedder-policy", ~c"require-corp"}, {~c"cross-origin-opener-policy", ~c"same-origin"}, {~c"cross-origin-resource-policy">

 [error] #PID<0.2024.8> running Pleroma.Web.Endpoint (connection #PID<0.1601.8>, stream id 48) terminated
                                                              Server: kongwoo.icu:80 (http)
                                                              Request: GET /users/seviche
                                                              ** (exit) an exception was raised:
                                                                  ** (Protocol.UndefinedError) protocol Phoenix.HTML.Safe not implemented for %{errors: %{detail: "Internal server error"}} of type Map. This protocol is implemented for the following type(s): Atom, BitString, Date, DateTime, Decimal, Float, Integer, List, NaiveDateTime, Phoenix.HTML.Form, Phoenix.LiveComponent.CID, Phoenix.LiveView.Component, Phoenix.LiveView.Comprehension, Phoenix.LiveView.JS, Phoenix.LiveView.Rendered, Time, Tuple, URI
                                                                      (phoenix_html 3.3.1) lib/phoenix_html/safe.ex:1: Phoenix.HTML.Safe.impl_for!/1
                                                                      (phoenix_html 3.3.1) lib/phoenix_html/safe.ex:15: Phoenix.HTML.Safe.to_iodata/1
                                                                      (phoenix 1.6.16) lib/phoenix/controller.ex:772: Phoenix.Controller.render_and_send/4
                                                                      (phoenix 1.6.16) lib/phoenix/endpoint/render_errors.ex:78: Phoenix.Endpoint.RenderErrors.instrument_render_and_send/5
                                                                      (phoenix 1.6.16) lib/phoenix/endpoint/render_errors.ex:64: Phoenix.Endpoint.RenderErrors.__catch__/5
                                                                      (phoenix 1.6.16) lib/phoenix/endpoint/cowboy2_handler.ex:54: Phoenix.Endpoint.Cowboy2Handler.init/4
                                                                      (cowboy 2.10.0) /woodpecker/src/akkoma.dev/AkkomaGang/akkoma/deps/cowboy/src/cowboy_handler.erl:37: :cowboy_handler.execute/2
                                                                      (cowboy 2.10.0) /woodpecker/src/akkoma.dev/AkkomaGang/akkoma/deps/cowboy/src/cowboy_stream_h.erl:306: :cowboy_stream_h.execute/3

snott · 21 August 2023 07:29

because thats how akkoma displays profiles?

edit: okay it seems local users are displayed like /:userid, and remote are /user/:userid

sevichecc · 21 August 2023 09:04

But this route works in other instances, like: Akkoma

ilja · 21 August 2023 09:44

Afaik the /users/:userid route should indeed also work. What Akkoma version are you running? (Pls make sure to update to the latest version.) Is it OTP or from source? If from-source, what does elixir --version give you? Is it only on this one profile, or also others? Do you have the same result when you try to fetch them on the machine itself using localhost:port. I.e. status 200 for curl https://localhost:4000/seviche, and status 503 for curl https://localhost:4000/users/seviche?

sevichecc · 21 August 2023 12:43

Akkoma Version: * 3.10.4-0-g0af8e93 (OTP)

And all user profiles in kongwoo.icu have the same problem.

status 200: curl http://localhost:4000/seviche
status 500: curl http://localhost:4000/users/seviche

FloatingGhost · 21 August 2023 21:17

I think the only difference between the two routes is the preload

you wouldn’t happen to have set the preload setting to anything nonstandard would you?

sevichecc · 22 August 2023 06:57

My config is :

config :pleroma, Pleroma.Web.Preload, 
[providers: 
    [Pleroma.Web.Preload.Providers.User, 
      Pleroma.Web.Preload.Providers.Instance, 
      Pleroma.Web.Preload.Providers.StatusNet, Pleroma.Web.Preload.Providers.Timelines
    ]
]

Looks like nothing is nonstandard .

Would it be something related to unauthenticated restriction settings?

FloatingGhost · 22 August 2023 10:08

so the answer is yes, yes you are indeed using unusual preload settings

i don’t even think Pleroma.Web.Preload.Providers.StatusNet is a valid setting there???

statusnet is a phrase that has not been used for years, and there is no reference to it in the source code

sevichecc · 22 August 2023 16:58

But I found that the StatusNext setting is available in admin-fe:

The instance I am currently using has been migrated from Pleroma, is it possible that there are remnants of Pleroma causing this issue?

To troubleshot, I removed Pleroma.Web.Preload.Providers.StatusNet from the selected providers list. However, the 503 error persists.

ilja · 22 August 2023 18:42

The only one I have enabled is Pleroma.Web.Preload.Providers.Instance. Maybe try with just that?

If this doesn’t work; When did you move from Pleroma and from what Pleroma version? Maybe some rollbacks haven’t been applied. But I’m just guessing.

If you want to be sure it’s not weird config, you can try first to prune the prod.config.exs file and see if that helps. Only keep the config that is set during setup, see https://akkoma.dev/AkkomaGang/akkoma/src/branch/develop/priv/templates/sample_config.eex for the template. Make sure you keep a backup of your settings just in case, and restart the instance afterwards for changes to take effect.

If this doesn’t help, we can try resetting the config in the database as well. You can first dump all database settings and store it somewhere, see https://docs.akkoma.dev/stable/administration/CLI_tasks/config/#dump-all-of-the-config-settings-defined-in-the-database. Then you can dump all database settings with https://docs.akkoma.dev/stable/administration/CLI_tasks/config/#remove-all-settings-from-the-database. Then reboot and see if it helps.

If this helps, then you know it’s some config and you can try to restore the settings you need one by one.

If this doesn’t help, then I guess a next step could be to check if there’s anything weird with the users themselves in the database.