davidradl
commented
4 years ago In addition, I think that there are 2 types of error messages in the browser. 1) There are errors displayed to the user, using UI components, e.g. highlighting an invalid field with text, a popup with an error, highlighting parts of a displayed graph that have errors. Also a user log would be useful, containing meaningful translated content for the user. 2) Untranslated logging for diagnostics, not for consumption by the browser user - this would go to the javascript console.In time we should have levels of logging here if it becomes an issue for performance.
github-actions[bot]
For all cases where errors displayed by the browser should be looked up in a localization bundle and the parameters replaced. The error should indicate the system and user action to take as well as what has happened. The error should be understandable by the UI user.
I am thinking there are a number of cases:
1) The browser issues a call, and the javascript realises that the content is not valid, in this case no rest call is issued and the client needs to display an error message. 2) The browser issues a rest call and it fails prior to getting to the server code, in this case the client needs to display an error message 3) The browser issues a rest call and the UI server validation spots that there is something wrong with the request. In this case the UI server needs to pass back the error to the client. 4) The UI server issues the rest call to the back end server; this could be to an OMAS endpoint or a governance server (for open lineage). The rest call fails before it gets to the backend server. 5) The UI server issues the rest call to the back end server; this could be to an OMAS endpoint or a governance server (for open lineage). The rest call fails and the back end server returns a response indicating the nature of the error. In this case the error needs to be mapped by the UI server into something meaningful for the browser user. 5a)This means that the error in the response needs to contain structured fields indicating the context of the error that has occurred,. For example for an invalid parameter error to an omas, then the field in the request that is invalid needs to be returned. For an invalid non null npa userid, then the UI audit log this error, as this means that the configuration is incorrect. The browser should be sent an error without the failing NPA userid value. In this case the unauthorised status code should not be returned [https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.1] - as it would indicate that the client's userid is not authorised. 5b) It seems to me that http status codes from the rest calls made to the backend need to be mapped to https status codes in the response back to the browser. See https://softwareengineering.stackexchange.com/questions/329229/should-i-return-an-http-400-bad-request-status-if-a-parameter-is-syntactically. There is some debate, but it seems that an OK response could be returned with the body describing the actual error. In this case the javascript needs to check the response to see if it is an error orientated payload or the actual payload, the OMAS response objects contain the error details. It makes sense to me to populate the response object with the error code id and parameters to the javascript can then display it in a user centric manner.
The javascript in the UI uses a Polymer component to issue the rest calls. We have logic in a component called token-ajax.js. I am suggesting that an OK (200) would contain the error code, the error would then be process by the caller. If all these responses to the view services had the same format, then maybe we should notice the error and display it in a user centric translated error log. The calling component still needs to be made aware of the error, so it can decorate its components appropriately. There are cases where the rest call fails with a non 200 return code, for example if the logged in userid is not authorised.
I am interested in feedback and coming to a consensus around the approach to take here. @mandy-chessell @cmgrote @planetf1 @bogdan-sava @grahamwallis @danielaotelea