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

Trackers exceed cache size #52

Closed
codihuston opened this issue Feb 19, 2020 · 7 comments
Closed

Trackers exceed cache size #52

codihuston opened this issue Feb 19, 2020 · 7 comments
Labels
bug Something isn't working

Comments

@codihuston
Copy link
Owner

If a tracker is tracking, the size of the persistent storage cache (local storage) is increasing around 2KB per.

There is a snippet here that can calculate the remaining local storage space
https://stackoverflow.com/questions/4391575/how-to-find-the-size-of-localstorage

@codihuston codihuston added the bug Something isn't working label Feb 19, 2020
@codihuston
Copy link
Owner Author

codihuston commented Feb 19, 2020

Only increases as tracker is ticking, or on "play"

@codihuston
Copy link
Owner Author

codihuston commented Feb 19, 2020

Remarking out the cache.writeQuery() in updateTracker resolver reduces the increase by some few KBs, but not completely. Remarking cache.readQuery() removes the increase entirely!

@codihuston
Copy link
Owner Author

@codihuston
Copy link
Owner Author

codihuston commented Feb 19, 2020

Cache appears to be expanded due to the caching of the actual query/mutation execution; "application > storage > local storage > apollo-cache-persist", and inside of the that "ROOT_QUERY" and "ROOT_MUTATION" keys, there are mutations that are being cached per request addTracker()...|updateTracker(...); each key has its name set to stringified JSON of the entire object that is being updated...

Either need to find a way to delete those, or specify a key (so that only one key is used per updateTracker() mutation...

See: apollographql/apollo-feature-requests#4

@codihuston
Copy link
Owner Author

@codihuston
Copy link
Owner Author

          Object.keys(cache.data.data.ROOT_MUTATION).forEach(key => {
            // console.log("KEY", key);
            if (
              key.includes("updateTracker") &&
              key.includes(task.userTaskInfo.id)
            ) {
              delete cache.data.data.ROOT_MUTATION[key];
            }
          });
          Object.keys(cache.data.data.ROOT_MUTATION).forEach(key => {
            // console.log("KEY", key);
            if (
              key.includes("updateTracker") &&
              key.includes(task.userTaskInfo.id)
            ) {
              delete cache.data.data.ROOT_MUTATION[key];
            }
          });

codihuston pushed a commit that referenced this issue Feb 19, 2020
- after running the app overnight into about 1PM the next day, an
exception was thrown where the cache could not be written to since it
hand ran out of space
- I'm not sure why this occured since most of the data is repetitive,
and very small; Running snippet from:
https://stackoverflow.com/questions/4391575/how-to-find-the-size-of-localstorage
- the snippet in the forum shows the amount increasing slowly (~2KB) per
tick of one tracker

refs #52
codihuston pushed a commit that referenced this issue Feb 19, 2020
- I pinned down the issue to the results of the `mutation` for
`updateTracker()` being cached under the `ROOT_MUTATION` key in the
apollo cache, when persisted into local storage
- prior to writing to the cache, I am currently deleting those keys that
contain `updateTracker` and the `task.userTaskInfo.id` field
- if there is a way to specify keys under the `ROOT_MUTATION`, then I
should be able to rely on that instead of this cleanup...

closes #52
@codihuston
Copy link
Owner Author

Complete as of a1b6054

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Development

No branches or pull requests

1 participant