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

Storage: Improve local storage error handling #40434

Open
ifrost opened this issue Oct 14, 2021 · 1 comment
Open

Storage: Improve local storage error handling #40434

ifrost opened this issue Oct 14, 2021 · 1 comment
Labels
area/frontend crossroads-call If your team can’t decide on what to do with a particular issue.

Comments

@ifrost
Copy link
Contributor

ifrost commented Oct 14, 2021

What happened:

In numerous places local storage is updated without error handling. When quota is exceeded it may cause the app to break (like here) or if the error is caught by a component at some level it may break the component like below:

image

What is more, Grafana is inaccessible when local storage is not available:

What you expected to happen:

If local storage is not available or full:

  • Grafana should not break.
  • Values should be persisted only for the duration of the current session.
  • Maybe the user should be informed about the error?

How to reproduce it (as minimally and precisely as possible):

  • Add artificial items to the storage to increase taken space and try to save new items.
  • Disable local storage and access Grafana (e.g. running /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --disable-local-storage)

Anything else we need to know?:

Environment:

  • Grafana version: 8.2.x
  • Data source type & version: any
  • OS Grafana is installed on: any
  • User OS & Browser: any
  • Grafana plugins: N/A
  • Others: N/A
@joshhunt
Copy link
Contributor

We do have the app/core/store.ts which could serve as the interface for everything using local storage goes through, with better fallback for when localStorage is unavailable, but unfortuantely not everyone uses this.

Would be great to add better fallback to that class, and enforce it's usage through linting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/frontend crossroads-call If your team can’t decide on what to do with a particular issue.
Projects
Status: 📝 Future
Development

No branches or pull requests

4 participants