:wave: hi! we have a significant number of Apollo ...

# apollo-kotlin

[fred]

👋 hi! we have a significant number of Apollo internal errors happening constantly across all our apps and we're currently trying to understand why they're happening and what we can do about that — full original context is in this thread, but the summary is that writing to cache seems to fail consistently for some of our users and the main culprit seems to be `SQLiteBlobTooBigException`s

we're currently planning to experiment with different cursor size to see if that helps, but we would also love to hear from you on a few different points:
• can you think of anything else we could look into or investigate?
• have you seen any other similar cases like this before where we could try to extract a learning or insight from?
• would it be possible for the apolloExceptionHandler to expose more than just the exception thrown so we can maybe learn what are the queries causing the failure, or anything else that might help narrowing things down?

[bod]

The ideal would be to have access to the .db file when that happens, to investigate - of course that's not easy 🙂

We could certainly add more diagnostics to the exception surfaced through apolloExceptionHandler 👍

[bod]

(I think that cursor size link is incorrect)

[bod]

Do you store any "big" structures in your cache? Things like images or large lists?

[bod]

Looking at this comment on a past occurence of the same exception, the culprit was a base64 encoded image used as a mutation argument (arguments are stored part of the cache keys). Do you have anything like this by any chance?

[fred]

(I think that cursor size link is incorrect)

fixed it, thanks!

I don't think we have that, but we certainly have queries that are large — we're currently working to split them up but it requires quite some effort and it's something we'll have to address gradually

do you have a rough estimate of what "big" is? it would definitely be helpful if we could get more confidence they're the culprit so we can prioritize splitting them up

[bod]

It’s actually the size of records (or their keys) that’s likely causing an issue, not the queries per se - although they are related.
A record may have a lot of fields, or some fields that have a large value (including lists)? Do you notice anything when looking at the cache with the IDE plugin?
Difficult to quantify this though, especially since I don’t exactly understand what causes the exception. I guess that 2M window size is the max size that one record should be?

[fred]

so what you're saying is that even if we split our queries, if in the end we still end up with records that are too large, we would potentially still have the same problem? I'll spend some time with the IDE plugin to get a better idea on how large our keys and records can be, thanks

[bod]

If your cache keys are well configured, yes this is what's expected since the fields will end up in the same records thanks to the normalization process.

Yes, often, having a good look at what's inside the cache can be insightful and maybe reveal some issues.

[Eduard Boloș]

Hello! Circling back to this, as I was working on increasing windowSizeBytes, it hit me why the `SQLiteBlobTooBigException`s could be occurring. We are caching pretty much all executed operations, and we have many top-level mutations that can be executed tens of times daily with different arguments (thus having different cache keys) by some of our most active users. This results in QUERY_ROOT holding many fields, growing out of proportions.
Whereas not everything really needs to be cached, many times we want some object from the cache to be refreshed with the data from the response, so we can't use doNotStore() most of the time. Plus that people would forget to do it when needed 😄 Ideally we'd have an option for desired operations to update in the cache the objects inside the response that are already present in the cache, but without adding a field to the parent record / QUERY_ROOT for the top level object, but not sure if this makes sense.
Looking a bit more into this, I realised that the new normalized cache library could provide some better solutions, like using cache control and removing stale fields, or removing certain operations and dangling references. But it's in alpha, so we'll wait before considering it for real.
Anyway, I don't expect any action from this, but if you have any opinion, I'd be curious to hear it 😄

[bod]

Thanks a lot for the follow up!

With the new cache, you can exclude certain types to be stored in the cache, and also use a FieldKeyGenerator to e.g. exclude certain arguments from the name of fields in your root record (example here). I'm not 100% sure this covers what you'd like to do - but it looks like it 🙂

[Eduard Boloș]

good to know 🙂 we'll definitely have a closer look once the new cache graduates. thanks!