Skip to content

fix: only invalidate cache tags when mutation response body reports success (#1162)#1237

Open
wendyamoni-creator wants to merge 1 commit into
solutions-plug:mainfrom
wendyamoni-creator:fix/cache-tags-are-invalidated-even-when-a-mutation
Open

fix: only invalidate cache tags when mutation response body reports success (#1162)#1237
wendyamoni-creator wants to merge 1 commit into
solutions-plug:mainfrom
wendyamoni-creator:fix/cache-tags-are-invalidated-even-when-a-mutation

Conversation

@wendyamoni-creator

@wendyamoni-creator wendyamoni-creator commented Jul 27, 2026

Copy link
Copy Markdown

Summary

Fixes #1162 — cache tags were being invalidated for any POST/DELETE that returned HTTP 2xx, regardless of whether the response body's success field indicated a business-logic failure.

Root Cause

The invalidation block in request() fired unconditionally on every 2xx mutation response:

// before
if (method === "POST" || method === "DELETE") {
  if (options.cacheTags?.length) {
    apiCache.invalidateByTags(options.cacheTags);
  } else {
    apiCache.invalidateByPattern('.*');
  }
}

newsletterSubscribe and newsletterUnsubscribe both carry [CacheTag.NEWSLETTER, CacheTag.STATISTICS] tags and can return { success: false, message: '...' } with HTTP 200. A rejected subscription was therefore busting the statistics cache, triggering an unnecessary refetch and a brief stale flicker for unrelated cached data.

Fix

// after — guard invalidation behind the response body's success field
if (method === "POST" || method === "DELETE") {
  const bodyObj = (typeof data === 'object' && data !== null)
    ? data as Record<string, unknown>
    : null;
  const succeeded =
    bodyObj === null ||
    !('success' in bodyObj) ||
    bodyObj['success'] === true;
  if (succeeded) {
    if (options.cacheTags?.length) {
      apiCache.invalidateByTags(options.cacheTags);
    } else {
      apiCache.invalidateByPattern('.*');
    }
  }
}

Rules:

  • No success field → treat as success (non-envelope endpoints like resolveMarket)
  • success: true → invalidate as before
  • success: false → skip invalidation entirely

Tests

Added 3 new tests to the Cache invalidation strategy suite in client.test.ts:

  1. success:false — 200 response with { success: false } does NOT invalidate cache
  2. success:true — 200 response with { success: true } DOES invalidate cache
  3. no success field — 200 response without success key DOES invalidate cache (non-envelope endpoint)

Checklist

…uccess

request() was invalidating NEWSLETTER/STATISTICS cache tags for any
POST/DELETE that returned HTTP 2xx, without inspecting the parsed
payload's success field. newsletterSubscribe / newsletterUnsubscribe
can return { success: false, message: '...' } with a 200 status, so a
rejected subscription was still busting the statistics cache — causing
an unnecessary refetch and a brief stale flicker for unrelated data.

Fix: in the mutation cache-invalidation block, derive 'succeeded' from
the response body:
  - no success field present → treat as success (non-envelope endpoints)
  - success: true           → invalidate as before
  - success: false          → skip invalidation entirely

Tests added to 'Cache invalidation strategy' suite:
  • success:false 200 response → cache NOT invalidated
  • success:true  200 response → cache IS invalidated
  • no success field present   → cache IS invalidated (non-envelope)

Closes solutions-plug#1162
@drips-wave

drips-wave Bot commented Jul 27, 2026

Copy link
Copy Markdown

@wendyamoni-creator Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug] Cache tags are invalidated even when a mutation's response body reports business-logic failure

1 participant