Skip to main content

​
Invalidation Audit

​
Objective

Review every invalidation block and make sure it is necessary, non-overlapping, and aligned with the shared key factory.

​
Core Rule

Invalidate only when cached data may now be stale, and target the narrowest key family that still refreshes all required dependents.

​
What To Remove

​
Overlapping parent and child invalidations

This pattern is usually redundant:
When the actual query key is ['accounts', userId, 'list'], one correctly chosen invalidation should usually be enough.

​
Unnecessary refetchQueries

Keep refetchQueries only when UX truly needs immediate visible refresh after the mutation flow completes. If invalidateQueries on an active query already gives the needed behavior, remove the extra refetchQueries.

​
Dead key families

Remove invalidation calls for keys that are not used by any active query.

​
File-By-File Review Requirement

Each file that uses invalidateQueries should be reviewed for:
  1. actual query keys in play
  2. whether the invalidated queries are active, inactive, or nonexistent
  3. whether the same query is being hit by multiple parent/child keys
  4. whether downstream domains truly depend on the mutation

​
Review Procedure

  1. Identify the mutation or stale-data event.
  2. List the actual affected query hooks.
  3. Map each hook to its factory key.
  4. Choose the narrowest invalidation key that covers the needed hooks.
  5. Keep refetchQueries only if immediate refresh is required.
  6. Remove all overlaps.

​
Special Focus Files

  • components/add-account-widget.tsx
  • components/manage-hidden-accounts-dialog.tsx
  • app/(app)/accounts/page.tsx
  • app/(app)/dashboard/page.tsx
  • app/(app)/assets-liabilities/page.tsx

​
Acceptance Criteria

  • each invalidation block has a clear reason
  • overlapping invalidations are removed
  • dead or unused key invalidations are removed
  • all invalidations use globalKeys or userKeys(userId)