Read operations throw a QuotaExceeded err on browser

[matibat]

Description

The stash package has functionality around cache, such as the hitCount: In order to track the number and keep it updated there's a write operation after a cache hit, which may cause a QuotaExceeded error. The same happens for write operations, but that's expected.

Question(s) - Am I missing some configuration or error handling? Is there any way of disabling the functionality I don't use? Any suggestion? :)

Environment

$ flutter --version
Flutter 3.10.0 • channel stable • https://github.com/flutter/flutter.git
Framework • revision 84a1e904f4 (3 weeks ago) • 2023-05-09 07:41:44 -0700
Engine • revision d44b5a94c9
Tools • Dart 3.0.0 • DevTools 2.23.1

dependencies:
  [...]
  stash: ^4.3.2
  [...]
  stash_shared_preferences: ^4.6.2

    return store.cache<Uint8List>(
      name: defaultCacheName,
      maxEntries: maxEntries,
      evictionPolicy: null,
    );

[matibat]

Please let me know if you need more info, I'm glad to help :)

[ivoleitao]

Hi,

I think you should try to use another backend as shared_preferences is a bit limited on web. I didn't do a lot of tests on web but I know that stash_hive or stash_sembast_web should work.

This is really the way the library works, It needs hitCount updates to support the LFU eviction policy but not only that, to update the access time as well which is used by the LRU eviction.

[matibat]

Hey :)

Thanks for the suggestion!

We worked around the errors by setting a smaller maxEntries cache limit so we always have some room for stash to do their write operations.

So, would you say it's the App's responsibility to manage the available space? It indeed makes sense to me for the write operations, but what about the read operations? Any chance that we have a "force read" functionality that lets you read items even when the library cannot update those pieces of data?

[ivoleitao]

Hi,

Using stash_shared_preferences as cache was something that I added support but to be honest it's not something that I would use in production. shared_preferences is very limited for that. To use as a vault it's ok but as a cache it's not really something that can recommend due the the limitations of that backend on web that I can't really control.

Support for web is still very limited and for web stash_hive or stash_sembast_web are really the only ones that i'm aware that can offer you a more robust backend with stash as a mediator. at least on web.

For caches and vaults every read results in a write (as I need to record last access time), and the best that I can do is to implement some form of rate limiting but right now I don't have it on my pipeline