Suboptimal Caching Behavior for Public Queries
Current Behavior
- Query results are only cached per user session
- Cache is not shared between different users or sessions
- Even public queries with stable parameters require fresh DB hits for each new user/session
- Example: Product listing queries with same filters/pagination hit DB for each new visitor
Expected Behavior
- Public queries with identical parameters should be cached across users/sessions
- Queries that don't depend on user-specific data (like
ctx.auth.getUserId()) should leverage shared cache
- Cache invalidation should only occur when underlying data changes
Impact
- Increased database bandwidth consumption
- Higher latency for common queries
- Unnecessary load on database for identical queries
- Cost implications for high-traffic applications47 Replies
Thanks for posting in <#1088161997662724167>.
Reminder: If you have a Convex Pro account, use the Convex Dashboard to file support tickets.
- Provide context: What are you trying to achieve, what is the end-user interaction, what are you seeing? (full error message, command output, etc.)
- Use search.convex.dev to search Docs, Stack, and Discord all at once.
- Additionally, you can post your questions in the Convex Community's <#1228095053885476985> channel to receive a response from AI.
- Avoid tagging staff unless specifically instructed.
Thank you!
If a query doesn't read
ctx.auth, it is cached between users.
Queries that do authentication and authorization checks are trickier. You usually don't want to just check that the user is logged in, you want to check that they have access to the requested data. So we need to run custom code based on the user and on the fetched data. Making sub-queries cachable is an active area of development. Thanks for bumping it, it helps with prioritizingthis problem might happen only for paginated queries
i even wrote own client side implementation where id is always same (caused cache invalidation on every component mount). that helped only if the query is used within same session.
new user or new user session = no cache
Ah yes paginated queries are only cached in certain circumstances. I see you discovered the
id field which intentionally busts the cache when it's not safe. I don't think this is related to users being logged in. What is your desired behavior?can be tested with opening private tab (no user data)
paginated queries are used on large datasets. that means every user and every new user session will fetch database again
this is causing large database comsumsion
and without this id "fix" it causing database hits even within same session if id increases
so for some reason paginated queries cache is connected to user session and there is no reason for this
do your paginated queries not call
ctx.auth?no they dont
all parameters are stable
then this behavior is unexpected
i'll look into it
you can test it even for same user opening private tab
this id thing needs also another solution
thanks
i came into this by seeing large database consumtions of paginated queries
without caching when app is live it will hit all limits within a day
okay i see this behavior. i think it's due to this feature: https://stack.convex.dev/fully-reactive-pagination . i'm not sure if we can do anything about it in the short term, but we'll discuss. you can control your own caching by writing your own pagination with https://stack.convex.dev/pagination , but it's pretty tricky
Fully Reactive Pagination
Paginating over large datasets is tricky when the data is changing. Naive approaches result in missing or duplicated data. The trick is to rewrite lim...
Take Control of Pagination
Convex offers robust control over pagination with a powerful function, getPage, enabling complex edge cases. In this article, we go over how to use th...
I understand. Thanks for checking out. Would be great to find easier solution than custom pagination
Also if you want to turn off the reactive-pagination-guarantees, you can use
import { paginator } from "convex-helpers/server/pagination"So use different paginator
Yes. The risk is that pages might not be contiguous if there are insertions/deletions. But it does make caching work just like any other query
well i see its different syntax and need to rewrite queries
did not help. first query after signin is not cached
params are same
i still think there is problem not only with paginated queries but queries in general
even non pagianted queries are sometimes not cached for no reason
this is everything for same user but after login. this is simple query without any dynamic params
i am pretty sure queries are not cached between different sessions
Can you provide the source code of the query?
The query cache doesn't know what a session is, so this seems unlikely to me
it doesnt depend on query code it happens for every query
please look at the screenshot query is not used from cache when user logs in after findorcreateuser
please try to login again and use same query
here is serverside query for example
eveything static data
i can repro. will look further
maybe this will also solve paginated problem
pretty sure the problem is that query cache is connected to user session id
yeah it does seem like that's the problem. i don't know why i thought query cache would be shared between user logins
What's the reason why it should not be shared betweens user sessions and different users for public queries?
It should. I think this is a missing feature (clearly useful to the extent that several of us thought it was already implemented). We'll probably implement it soon. Sorry about this missing feature
please update me later if a fix is planed. thanks
i dont know otherwise how to solve large database badwith consumtion for alot of users
any info maybe regarding this? 🙂
it's going to happen, I'm not going to put anyone on the hook with a deadline 😛
we agree this is the right behavior, we'll update this thread with more when we know
thank you
it may take a few days to deploy, but the code is written https://github.com/get-convex/convex-backend/commit/350accbe843d4e807b6089cf331c94124896e1ca
GitHub
[ENG-8173] share query cache for queries that don't check auth (#32...
Detect in the isolate whether
ctx.auth.getUserIdentity is ever called. If not, store the query result with identity: None in the query cache.
When checking whether a cache entry matches, we fi...great thank you
appreciate your job
hey Lee can you check please if the change is live? seems not yet
That's correct, it's not.
we're deploying that change ^ today. however, i just realized there are cases where it still doesn't cache when it should. we're continuing to work on it, but it may take a few more days.
specifically, if two users request the same query at the same time, we don't know yet whether the query will check
ctx.auth so the query executes twice. this happens frequently if both users are subscribed to the same query and the data changes, because then both queries rerun at the same time. 😢ok understand thanks
the full change has deployed today
there is still a problem that paginated queries are not cached
but dont know if it depends on users session of queries parameters
i dont mind to pay more for subscription. but this database usage of paginated queries is killing me. this is just within 2 days after launching the app with 3k users
This is including your hacky thing that sets the pagination id to 0?
We were thinking of shipping that change officially, but if you're still not getting enough caching even with that change, we would like to determine why
yes with id 0
this is is dynamic query. it doesnt depend on user but depends on pagination and products filter + combines results from multiple tables