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

Improve error handling on the frontend #2609

Open
2 of 3 tasks
obulat opened this issue Jul 11, 2023 · 1 comment
Open
2 of 3 tasks

Improve error handling on the frontend #2609

obulat opened this issue Jul 11, 2023 · 1 comment
Assignees
Labels
🕹 aspect: interface Concerns end-users' experience with the software ✨ goal: improvement Improvement to an existing user-facing feature 🟨 priority: medium Not blocking but should be addressed soon 🧱 stack: frontend Related to the Nuxt frontend ⛔ status: blocked Blocked & therefore, not ready for work

Comments

@obulat
Copy link
Contributor

obulat commented Jul 11, 2023

Problem

Our error handling is inconsistent and incomplete. We do not show error pages for some client errors, which causes errors down the line. This is very visible in the Sentry dashboard, where we get errors on the single result pages that are actually caused by 429 errors on the search pages.
The users don't get a clear indication of what they can do (how long they should wait) when they get 429.
The errors we do send to Sentry do not have enough information for us to resolve them.

Description

On errors, the front end should show error pages that clearly indicate why the error happened and what they can do next.
We should not hide or ignore the errors that prevent further requests from being successful.
To help solve the errors, we should capture the relevant error information in Sentry.

Outlined Steps

These tests should test the search and single result pages, and for errors thrown on the server and only on the client.

Kinds of errors

404 for pages that do not exist (openverse.org/nonexistentpage)
404 for single media result pages with non-existent id
429 for throttled requests
500 for API internal server error (can be the same as no. 1?)
Timeout errors

Special cases

What should we show for the following client-side errors:

  1. For All content view: what should be done when only one of the media types received an error?
  2. Errors on the "Load more" fetching?
  3. Should we display an error when there is an error loading Related media, or just hide the section?

Related issue: #511

The media store should set the fetchState.fetchingError errorStatus and message, and re-throw the original error.

The components (search.vue) or middleware (search.ts) should have a catch clause in the fetch function. Here, the error should be sent to Sentry, and the app should redirect to the error page that uses fetchState.fetchingError.

Update the search.vue component

The fetch method should capture error in Sentry and redirect to the error page if necessary.

Update the search middleware

The middleware should fetch media on the server and redirect to the error page if necessary.

@obulat obulat added 🟧 priority: high Stalls work on the project or its dependents ✨ goal: improvement Improvement to an existing user-facing feature 🕹 aspect: interface Concerns end-users' experience with the software 🧱 stack: frontend Related to the Nuxt frontend labels Jul 11, 2023
@github-project-automation github-project-automation bot moved this to 📋 Backlog in Openverse Backlog Jul 11, 2023
@obulat obulat moved this from 📋 Backlog to 📅 To do in Openverse Backlog Aug 15, 2023
@obulat obulat moved this from 📅 To do to 🏗 In progress in Openverse Backlog Aug 21, 2023
@obulat obulat added the ⛔ status: blocked Blocked & therefore, not ready for work label Oct 23, 2023
@obulat obulat moved this from 🏗 In progress to ⛔ Blocked in Openverse Backlog Nov 13, 2023
@sarayourfriend
Copy link
Collaborator

@obulat what is this blocked on?

@obulat obulat added 🟨 priority: medium Not blocking but should be addressed soon and removed 🟧 priority: high Stalls work on the project or its dependents labels Aug 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🕹 aspect: interface Concerns end-users' experience with the software ✨ goal: improvement Improvement to an existing user-facing feature 🟨 priority: medium Not blocking but should be addressed soon 🧱 stack: frontend Related to the Nuxt frontend ⛔ status: blocked Blocked & therefore, not ready for work
Projects
Status: ⛔ Blocked
Development

No branches or pull requests

2 participants