Error 500 from records API when in violation of a not-null constraint

[seancolsen]

Reproduce

1. Use the front end
2. Open a table where at least one column has a NOT NULL constraint set
3. Click the + icon at the bottom left of the table to begin adding a new record.
4. Observe a request to http://localhost:8000/api/v0/tables/24/records/ that
5. Observe HTTP response code of 500. The response needs to conform to our error structure, to-be-decided in Define common error structure #560. In particular, for Improve UX when adding new records to a table with a NOT NULL column #775 I need a structured machine-readable way to know which column(s) were in violation of the constraint.

Related to #858

[kgodey]

Moving this to the "Working with Tables" milestone since it blocks #775.

[seancolsen]

Marking this is unblocked since #560 is complete.

[dmos62]

Unless we split this into two issues, this is still blocked. The two issues would be:

1. handle the input, so that we would return an HTTP 4xx instead of 500;
2. adhere the API response to the new error spec.

Task 2 is still blocked pending error reporting implementation/concretization tracked in #883.

Edit: oh, I see @silentninja is alread on this.

[seancolsen]

@dmos62 As I see it, #883 is a large issue that requires many small tasks, one of which would be closing this ticket. To put that another way, to close #883 we'll need to make sure all our endpoints, and all the HTTP methods, and all error scenarios adhere to to the new structure. That's potentially a lot of small independent tasks. This ticket is tracking one error scenario for one HTTP method for one endpoint. And unlike a lot of the other small tasks within #883, this one is blocking a front end ticket, so I think it's worth keeping this ticket separate from #883 and prioritizing it over all the other small tasks which #883 encompasses. No need to close #883 before starting work on this ticket.

[seancolsen]

#1017 didn't fully address the concerns raised in this ticket.

Specifically, in step 5:

I need a structured machine-readable way to know which column(s) were in violation of the constraint.

As such, I've opened #1051 to track progress on that.