Bug #2891
Updated by Tom Clegg almost 10 years ago
Examples
* A user recently tried to view a collection they did not have permission to read (see #2890). The API server returned 404 for this request, and Workbench rendered a 422 Fiddlesticks. Workbench should render a more-specific 404 for this specific error.
* If an object is not found, but the desired/expected object type can be determined, offer a link to a "search all X" page.
* Unexpected errors from the API server should be presented with some more boilerplate rather than just "blah [API 422]".
** "Workbench received an error response from an Arvados API method. The details of the request and response follow:"
** Show request URL (but avoid showing posted parameters, in case they are huge or include API tokens)
** Show pretty-json-formatted API response in a PRE block
** Show timestamp of request or response (and, perhaps better: on the API server side, include some sort of unique identifier in each error response, like timestamp+random, and send that to logger.error as well. Workbench can also log that ID when rendering an error page. This would make it much easier for a server admin to cross reference a user's error report / screen capture with the relevant parts of the Workbench and API log files.)
** Suggest an appropriate next step. "It's possible that you can fix this by refreshing the page, but it's more likely a software bug: either API server is not behaving the way Workbench expects, or Workbench has made a mistake by offering to let you do something that isn't really possible. In that case, your best option is to report this information to the server administrator via {Rails.configuration.bug_reporting_contact_link}."
* Error page should not give the appearance of being logged out if in fact the user is still logged in.