Better error pages?

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개의 좋아요

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개의 좋아요

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개의 좋아요

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개의 좋아요

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?

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개의 좋아요

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개의 좋아요

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

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개의 좋아요

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개의 좋아요

수년간 많은 개선을 해 왔으며, @david가 테마 오류 패널을 도입했습니다. 이 패널은 곧 비추천(deprecation) 오류 패널 지원으로 확장될 예정입니다.

또한, 많은 문제를 처리하는 안전 모드도 갖추고 있습니다.

OP에서 언급된 문제가 완전히 해결되었다고 말하기는 어렵지만, 수년간 상당한 진전을 이뤘습니다.

4개의 좋아요