Non-semantic use of error code 400

Observed behavior

A couple of places, API calls will return HTTP 400

A 400 means that the request was malformed. In other words, the data stream sent by the client to the server didn’t follow the rules.

If the username already exists (see: https://github.com/learningequality/kolibri/pull/3125 ) then the HTTP status code 400 is used as the sole condition.

Another example:

https://github.com/learningequality/kolibri/blob/79c6a9046b153656c61c01b9375109d3ff395ae5/kolibri/plugins/user/assets/src/views/sign-up-page/index.vue#L192

I don’t think it’s that bad, but I don’t think we should assume anything from the HTTP status code. Some people even argue that 200 is more correct for a form processing where data doesn’t validate… because frankly, there’s no exception taking place in the server, and the client is using the API correctly.

Let’s find and add a standard for form validation errors? cc: @mrpau-eugene @indirectlylit @rtibbles

Expected behavior

Backend errors should resolve through correct error codes that do not mis-guide developers.

User-facing consequences

None

Errors and logs

n/a

Steps to reproduce

n/a

Context

n/a

[indirectlylit]

Let’s make this a focus of the next milestone after 0.9. I think we should take a step back and do some design work on all this together.

[indirectlylit]

This should be addressed. @ralphiee22 mind linking your error-handling PR here?