Better Error Support

It would be good to have proper support for error pages:

  • Currently, the nginx server will serve up the wacc_500.html page for a 502 bad gateway, 503 service unavailable, and 504 gateway timeout: these all suggest the server is down.
  • 401 unauthorised (?) and 404 not found can be handled directly by the server.

Otherwise, it would be good to serve back the following error codes in various conditions (the frontend should be able to make a suitable pop-up for these, including 401?):

  • 408 timeout: this would be relevant for interactive I/O performed by program execution ( #3), when that eventually lands.
  • 424 failed dependency: this would be relevant again, for the above, if we go with a two-step "compile first" then "connect to run" for interative emulation and the compile failed.
  • 429 too many requests: not sure how we'd generate this one yet, but it would be good to try and prevent "programmatic" use of the server, i.e. students polling for behaviours on every CI push
  • 400 bad request and 500 internal server error: a 400 from the frontend suggests a failure in the JSON encoders, which is a definite bug, and 500 is some unhandled error from the server. In both of these cases we want to request that the user make a bug report -- not sure how much information they'll receive about this though. Note that compiler crashes should be handled separately perhaps 599? A missing compiler should definitely return a 500, we've seen this locally reported as a 400
  • 413 payload too large and 507 insufficient storage: this should be raised if the server runs out of space to store files sent to it or if the file sent is so big that it'll cap out the RAM of the server when processing.
Edited by Jamie Willis