Sign in before continuing.
Better Error Support
It would be good to have proper support for error pages:
- Currently, the
nginxserver will serve up thewacc_500.htmlpage for a502 bad gateway,503 service unavailable, and504 gateway timeout: these all suggest the server is down. -
401 unauthorised(?) and404 not foundcan 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 requestand500 internal server error: a400from the frontend suggests a failure in the JSON encoders, which is a definite bug, and500is 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 largeand507 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