Unexpected query invalidation behavior — mutation waits for refetches across unrelated queries
Hi Convex team,
I built a minimal reproduction and wanted to report the unexpected behavior I observed when calling a mutation that inserts a new message.
Short summary
- Mutation (DB write) completes quickly on the server (~0-30ms).
- The client-side mutation promise does not resolve immediately — it waits while multiple queries refetch.
- Convex revalidates all queries that touch the
- This causes the mutation to appear to take the combined refetch time on the frontend (in my test ~765ms), even though the backend mutation duration is ~0ms.
Reproduction steps (repo included)
1. Clone the public test repo: https://github.com/williamneves/convex-lab
2. Run Convex dev:
3. Start the frontend (Bun/Next):
4. Click “Seed Users” and “Seed 20 Messages”.
5. Set a cutoff date and click “Generate Before Message” or “Generate After Message”.
6. Watch the Timing Analysis card and Convex logs.
Observed logs (snippet)
- insertMessage logs (server):
— Convex shows the mutation finished in ~0–26ms in the server logs.
- Queries revalidation logs (server):
- Frontend timing (UI card):
Observed behavior summary
- The mutation completes on the server almost instantly.
- The client-side mutation promise resolves only after all related queries have re-fetched (including ones whose args should not match the new message).
-
Expected behavior
- Mutation resolution should reflect the mutation’s server-side work (DB write + any server work).
- Query invalidation/refetch should be triggered but should not block the mutation promise resolution unless explicitly configured to do so.
- Ideally, invalidations should be scoped: only queries whose arguments indicate they could be affected by the mutation should be revalidated.
Questions / requests
1. Is the Convex client intended to wait for query revalidations before resolving a mutation promise? If so, is this configurable (non-blocking refetch vs. blocking)?
2. Is there a way to scope invalidation so only queries with matching args are revalidated (so
3. If current behavior is intentional, can you document when mutations block on refetches, and whether there’s a way to change that behavior (e.g., optimistic updates, fire-and-forget revalidation)?
4. I can provide the small test repo link, console logs, and server logs; what additional info would be most helpful for triage?
Repository & logs
- Repo: https://github.com/williamneves/convex-lab
- I can attach full terminal logs and Convex function logs if useful.
I built a minimal reproduction and wanted to report the unexpected behavior I observed when calling a mutation that inserts a new message.
Short summary
- Mutation (DB write) completes quickly on the server (~0-30ms).
- The client-side mutation promise does not resolve immediately — it waits while multiple queries refetch.
- Convex revalidates all queries that touch the
messagesgetAllMessages- This causes the mutation to appear to take the combined refetch time on the frontend (in my test ~765ms), even though the backend mutation duration is ~0ms.
Reproduction steps (repo included)
1. Clone the public test repo: https://github.com/williamneves/convex-lab
2. Run Convex dev:
npx convex dev3. Start the frontend (Bun/Next):
bun run dev4. Click “Seed Users” and “Seed 20 Messages”.
5. Set a cutoff date and click “Generate Before Message” or “Generate After Message”.
6. Watch the Timing Analysis card and Convex logs.
Observed logs (snippet)
- insertMessage logs (server):
— Convex shows the mutation finished in ~0–26ms in the server logs.
- Queries revalidation logs (server):
- Frontend timing (UI card):
Backend Mutation: 0msDB Op: 0msFrontend Total: 765msObserved behavior summary
- The mutation completes on the server almost instantly.
- The client-side mutation promise resolves only after all related queries have re-fetched (including ones whose args should not match the new message).
-
getAllMessagesExpected behavior
- Mutation resolution should reflect the mutation’s server-side work (DB write + any server work).
- Query invalidation/refetch should be triggered but should not block the mutation promise resolution unless explicitly configured to do so.
- Ideally, invalidations should be scoped: only queries whose arguments indicate they could be affected by the mutation should be revalidated.
Questions / requests
1. Is the Convex client intended to wait for query revalidations before resolving a mutation promise? If so, is this configurable (non-blocking refetch vs. blocking)?
2. Is there a way to scope invalidation so only queries with matching args are revalidated (so
getAllMessagesafter3. If current behavior is intentional, can you document when mutations block on refetches, and whether there’s a way to change that behavior (e.g., optimistic updates, fire-and-forget revalidation)?
4. I can provide the small test repo link, console logs, and server logs; what additional info would be most helpful for triage?
Repository & logs
- Repo: https://github.com/williamneves/convex-lab
- I can attach full terminal logs and Convex function logs if useful.
GitHub
Contribute to williamneves/convex-lab development by creating an account on GitHub.
Join the Convex Discord! Explore Convex, the backend platform that keeps your app in sync.
15,138Members
Resources
Was this page helpful?
