For example, a malformed UUID used in the /template/{id} endpoints should return 400 BAD REQUEST and not 500 INTERNAL ERROR
A natural part of this fix is to check all the data models that are passed between components (eg what the API sends to the processing component) and ensure they are consistent. A lot of the runtime failures we experience are caused by the fact that the models are not originating from a single source of truth. For instance, the processing component might not set a field called details in its response (because within processing, details is not correctly marked as a mandatory field) and then the API component fails to parse the response (because within API, details is marked as a mandatory field). This is clearly a programmer error but in addition to trying to eliminate all of these, I propose we prepare to handle any such leftover bugs ‘gracefully’: we should catch exceptions caused by schema validation and at least report them in a readable form. We can consider keeping the actual outgoing response clean with a 500 error and a short, sanitized message but then logging a readable error in the meantime for later debugging and analysis.
For example, a malformed UUID used in the
/template/{id}endpoints should return400 BAD REQUESTand not500 INTERNAL ERRORA natural part of this fix is to check all the data models that are passed between components (eg what the API sends to the processing component) and ensure they are consistent. A lot of the runtime failures we experience are caused by the fact that the models are not originating from a single source of truth. For instance, the processing component might not set a field called
detailsin its response (because within processing,detailsis not correctly marked as a mandatory field) and then the API component fails to parse the response (because within API,detailsis marked as a mandatory field). This is clearly a programmer error but in addition to trying to eliminate all of these, I propose we prepare to handle any such leftover bugs ‘gracefully’: we should catch exceptions caused by schema validation and at least report them in a readable form. We can consider keeping the actual outgoing response clean with a500error and a short, sanitized message but then logging a readable error in the meantime for later debugging and analysis.