API Error responses and Interviewer Error handling

These have become a mess after my overly hasty refactoring.

Before Server could import files, we had a simple model whereby errors during session import (originating for example in ProtocolManager or SessionDB would throw Error instances of various custom types. These error objects would arrive at the error handlers in DeviceAPI where they would be given a status code based on their type, and then this would be sent to the Interviewer client directly. Errors all the way down!

When we implemented file import of sessions, we wanted much more detailed error information. For example, a file could contain multiple sessions, with each session potentially having multiple issues. There could also be multiple files within a single import task. Displaying this meaningfully back to users as feedback about how an import process went required the ability to group the error list by any of these properties. Because of this, we needed to track case ID and filename in addition to the already existing error message, and to keep the properties themselves separate (i.e we couldn't simply create an error string concatenated with these parameters).

A further complication is that because of the way the import process is structured (as a series of nested promise chains), there is no simple way for an error generator that is deeply nested to know about the macro context. For example, a function that inserts the session into the database may fail, but it does not know the case ID of the session (one level up, where session variables were validated), or the file that the session is within.

I therefore created a constructErrorObject helper that was designed to sit in the .catch() blocks at various levels in the import promise chain, and add the information relevant to that level. As an error propagated up the promise chain, caseID and filename could be added appropriately, until a final promise rejection containing the object. This works perfectly for file imports, but breaks the logic of the client server API completely.

Fixing this issue will involve harmonising these two processes. Specifically:

Create definitive central error message definitions that cover all error types
Remove the use of custom error types in the client server API, and replace with rich error objects. Continue to use appropriate error codes

complexdatacollective / Server

API Error responses and Interviewer Error handling #304