Better Error Support
It would be good to have proper support for error pages:
- Currently, the
nginx
server will serve up thewacc_500.html
page for a502 bad gateway
,503 service unavailable
, and504 gateway timeout
: these all suggest the server is down. -
401 unauthorised
(?) and404 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
and500 internal server error
: a400
from the frontend suggests a failure in the JSON encoders, which is a definite bug, and500
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 perhaps599
? A missing compiler should definitely return a500
, we've seen this locally reported as a400
-
413 payload too large
and507 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