Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enh error handling #330

Merged
merged 23 commits into from
Feb 24, 2021
Merged

Enh error handling #330

merged 23 commits into from
Feb 24, 2021

Conversation

Axolotle
Copy link
Contributor

Changelog

The changelog is also there for me to remember to add this to the docs.

I called every API calls "request", and "actions" are requests that are usually triggered by the user and ends up in the history. "request" that have websocket: true are "actions".

  • reworked the whole process of making a call to the api:

    • new "request" object literal created at each request to represent an api call. It is used by the history, the waiting and error modal to display informations about the current/saved state of a request.
    • single methods (api.get(), api.post(), api.put(), api.delete()) to call for data that is cached or not (used to be separate functions), the difference is the uri arg which is a string for a regular call and an object literal ({ uri, storeKey } for a cached call.
    • full control over call options with different default depending on the method:
      • websocket opening
      • waiting modal opening
      • cache disabling (it is possible to bypass the cache with this))
      • initial, this is passed by api.fetchAll (see below) to every initial request (data needed by a view to render itself). The option allow to trigger a redirect if the view can't render so the user doesn't get stuck at a never ending skeleton.
    • removed api.getAll and replaced it by a more generic api.fetchAll that allow all method types.
      • will ensure that this will act as unique query (if activated, will set store.waiting to true then false only once).
      • will ensure that calls are made one after another to avoid weird websocket behavior
    • waiting screen opening is delayed a bit to avoid flickering for quick responses
  • added global error handler for unhandledrejection. This will catch errors that are thrown/rejected from inside a promise (all our api calls).
    A view (like form views for instance) can catch an error before the global handler and mitigate its propagation or display it independently.
    If nothing catch the error it will be displayed as a modal blocking the view (like the "waiting for server response"). The user will have to click on "Ok" to dismiss the modal or "Go back" to go to previous page if the error occurred as an initial query.
    This global handling only cares about APIErrors, regular javascript or other unexpected errors will still end up in the browser's console with no specific handling.

// Catching example in form to display form args errors.
api.post('apps', data).then(response => {
  this.$router.push({ name: 'app-list' })
}).catch(err => {
  // Here we want to handle errors that are 400 (Bad Request.
  if (err.name !== 'APIBadRequestError') throw err
  // could also be `if (err.code !== 400)` or `if (err isinstance APIBadRequestError)` but require to import the error
  this.serverError = err.message
})
  • APIError carries more information that is used to display proper error messages and can also be used when caught in a view to decide what to do with it:

    • name: Error's name as string
    • code: response's status
    • status: response's statusText
    • method: method of the guilty api call
    • path: api call's uri
    • request: some data produced by the api caller that is used in the history and overlay
  • new error: APIErrorLog. Thrown if the error response has log_ref in it. Setting this as an error on itself is convenient, it avoid checking this in a catch and let it be handled by the global catcher and redirect the user to the log

  • new error: APINotFoundError. (That should not append but just in case…)

  • add ability to review an error from the history (only those with websocket for now but won't be hard to inject a failed GET request to the history if we want to)

  • rework the error and waiting modal:

    • all have an header with the current request and its state
    • all displays the current websocket messages
    • the error modal tries to display everything it can
  • rework a bit the history (but will still need some improvements):

    • if you didn't know already you can drag the console header to change its size which will be remembered, you can close it by going down and it will reset to its default size.
    • new button last action which will auto display the last one.
    • new button in an action header to display again a related error.

misc short fixes:
- moved ErrorPage, DomainForm, PasswordForm into views/_partials to differentiate modular components from reusable view samples
- fixed error modal not closing itself if user hit the browser's back button.
- removed the Error route since every errors are now displayed in a modal
- removed the obligation of having a name that is at least 2 characters in user creation.
- fixed runDiagnosis missing execution
- fixed ToolLog's action Share with YunoPaste missing websocket message.
- fixed the ConfigPanel view, i mean it works for Archivist at least.

Preview

History
history-coll
history

Waiting Modal
waiting-current-messages

Error Modal
error-500-traceback2
error-500-traceback-messages

PR Status

Will require some tests since i had to modify quite a few lines dXD.

Copy link
Member

@alexAubin alexAubin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Uuuuuugh i'm not sure how to review this because ETOOMANYCHANGES ... Looking in diagonal this just looks legit to me and I would naively just yolomerge this to be able to test & iterate

@alexAubin
Copy link
Member

Alright idk, yolomerging, I may have some time tonight to re-test the entire new vuejs interface

@alexAubin alexAubin merged commit 91ed70e into dev Feb 24, 2021
@alexAubin alexAubin deleted the enh-error-handling branch February 24, 2021 16:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants