Better error pages?

feature
1

I think it’s time for some more complaint driven development!

Complaint: A disproportionate amount of posts here on meta are people whose discourse installs are broken.

Tired old Solution: We generally ask them to disable plugins and do a container rebuild. This tends to solve the problem 90%+ of the time.

Can we do better? I think so!

Proposal: Better error pages! We can detect if the user is an admin, and if so offer them the same suggestions we do here on meta. Try disabling your plugins. Try rebuilding your container. This seems like a no brainer for me if there are certain kinds of javascript errors (for example, can’t find module).

I would take it even further and put the advice on all error pages we display, but if you’re not an admin user, hide it behind a “Are you the administrator of this Discourse? Troubleshooting Tips” link.

Thoughts?

16 Likes
2

I thought that safe mode was going to solve these problems, but even with safe mode, it’s still possible for a plugin to muck up the works. How about I make a ./disable_plugins or ./debug script that would disable plugins and maybe even create a sanitized app.yml and/or log file?

2 Likes
3

The issue is people don’t even know how to enable safe mode, or where to start debugging. They need a starting point of advice when they get an error.

7 Likes
4

I’ve been thinking about this the last few days as I have been running a test vm and restoring a backup from our live forum. My test vm is a bit weak knee’d, so I’m never quite sure if the reason that I can’t load the webpage is that there is a fault, or if the vm is doing stuff in the background and the web pages aren’t up yet.

./launcher logs app is useful, if you know what to grep for, but it would benefit from something like

./launcher status app showing information like

mail: (disabled, down, up, starting)
database: (up, down, starting, errors)
webpages: (up, down, starting, errors)
nginx: (up, down, starting, errors)

so that one could check from a terminal if things are ok or not.

Even if all the “status app” spit out was “I’m broken” or “I’m busy starting” it would be a help.

5 Likes
5

How would this work? They are generally getting a white page due to JS errors caused by plugins, either server side or client side. How can we generate a page in those cases?

6

We can’t catch 100% of the errors but we can catch many of the most common ones. For example, one of the most common ones is trying to require a module that is no longer there. We can catch that error and show the page if it happens.

Part of it would be to figure out the top 5 most common exceptions thrown by broken plugins and catch those with the error page.

5 Likes
7

With that in mind, the top 2 come to mind for me are

  1. unable to load module
  2. any error with the word deprecated in it, as the method trying to be called doesn’t exist anymore.

Those are probably the two that have impacted me the most in the plugins I manage. I’ve tried searching a couple of the plugin topics to see what other errors have been reported, but really haven’t had much success with that approach yet.

7 Likes
8

3 posts were split to a new topic: Is there a block diagram that documents how Discourse works

9

I wonder what mileage we can get from a global javascript js error handler.

Another fancy option may be to set a timeout upfront that gets cleared after render, if nothing is rendered after N seconds display the “help me!!! my Discourse is all mucked up page”.

5 Likes
10

I think this was mostly resolved by the Safe Mode that @sam added in 1.7? At least for the commonest case of “rando third party plugin broke my site” anyway.

1 Like
11

We have made a lot of improvements over the years, @david introduced a theme error panel which is soon to be expanded to support a deprecation error panel.

We have safe mode as well which handles a very large amount of issues.

I would not say the issue in the OP is completely behind us, but we have made huge amounts of progress over the years.

4 Likes