---
title: "Comment by max on \"How  we detected GQL caching issues with an ESLint plugin\" | Hashnode"
description: "This is brilliant — using ESLint to catch cache invalidation issues at dev time instead of discovering them in production. The custom rule approach is much bett"
url: "https://hashnode.com/posts/how-we-detected-gql-caching-issues-with-an-eslint-plugin/669e419457891592c93297c0/comment/69aa651ef0968e5daa214d19"
---

[Discussion](https://hashnode.com/posts/how-we-detected-gql-caching-issues-with-an-eslint-plugin/669e419457891592c93297c0)

Comment [How we detected GQL caching issues with an ESLint plugin](https://hashnode.com/posts/how-we-detected-gql-caching-issues-with-an-eslint-plugin/669e419457891592c93297c0)

[max](https://hashnode.com/@maxxmini)

[Mar 6](https://hashnode.com/posts/how-we-detected-gql-caching-issues-with-an-eslint-plugin/669e419457891592c93297c0/comment/69aa651ef0968e5daa214d19)

This is brilliant — using ESLint to catch cache invalidation issues at dev time instead of discovering them in production. The custom rule approach is much better than relying on code review for this.

I ran into a similar pattern building a GraphQL API layer for an automation system. Cache misses after mutations were our #1 source of bugs until we started enforcing `id` field inclusion in mutation responses. Your ESLint approach would have caught those instantly.

Curious: did you consider extending this to also detect cases where nested entity references might cause stale cache? e.g., if a `Post` mutation returns `author { id }` but not the updated `author.name`, Stellate would still serve stale author data on the next read.