fix(query): don't reset keepUnusedDataFor on condition-skipped queries

[veksa]

Fixes #4480

If you keep dispatching initiate with { subscribe: false } for an arg that's
already cached, the data never gets removed. Each call pushes the expiry back, so
keepUnusedDataFor effectively turns into "keep forever" as long as something
polls that endpoint without subscribing.

Repro from the issue:

// default keepUnusedDataFor is 60s

// fetches and caches the data
store.dispatch(api.endpoints.myEndpoint.initiate({}, { subscribe: false }))

// 30s later — served from cache, no request
setTimeout(() => store.dispatch(
  api.endpoints.myEndpoint.initiate({}, { subscribe: false })
), 30_000)

// 61s later — data should be gone, but it's still cached
setTimeout(() => store.dispatch(
  api.endpoints.myEndpoint.initiate({}, { subscribe: false })
), 61_000)

Cause

The cache-collection middleware reschedules the removal timer whenever
canTriggerUnsubscribe matches, and it was matching queryThunk.rejected as a
whole.

When initiate(..., { subscribe: false }) hits a fresh cache entry, the thunk's
condition returns false and bails out before running. But the thunk uses
dispatchConditionRejection: true, so it still dispatches a rejected action —
one tagged with meta.condition === true. That made a plain cache hit look like
a finished request: the pending removal timeout got cleared and a fresh one
started, even though nothing was fetched and no subscription changed.

Fix

Ignore condition-based rejections when deciding whether to reschedule cleanup. A
query that bailed out via condition never ran and never touched a
subscription, so it shouldn't restart the removal timer. Real failures of
unsubscribed queries (meta.condition === false) still schedule removal as
before:

const isQueryThunkRejectedByError = (action: any) =>
  queryThunk.rejected.match(action) && !action.meta.condition

I also added a regression test that fires two initiate({ subscribe: false })
calls 30s apart and checks the entry is removed on the original deadline instead
of being pushed out.

[codesandbox]

Review or Edit in CodeSandbox

Open the branch in Web Editor • VS Code • Insiders

Open Preview

[netlify]

✅ Deploy Preview for redux-starter-kit-docs ready!

Name	Link
🔨 Latest commit	4aaa709
🔍 Latest deploy log	https://app.netlify.com/projects/redux-starter-kit-docs/deploys/6a5e1987632346000847aa46
😎 Deploy Preview	https://deploy-preview-5343--redux-starter-kit-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[pkg-pr-new]

Open in StackBlitz

@reduxjs/rtk-codemods

npm i https://pkg.pr.new/@reduxjs/rtk-codemods@4aaa709 -D

yarn add https://pkg.pr.new/@reduxjs/rtk-codemods@4aaa709.tgz -D

pnpm add https://pkg.pr.new/@reduxjs/rtk-codemods@4aaa709.tgz -D

bun add https://pkg.pr.new/@reduxjs/rtk-codemods@4aaa709.tgz -D

@rtk-query/codegen-openapi

npm i https://pkg.pr.new/@rtk-query/codegen-openapi@4aaa709 -D

yarn add https://pkg.pr.new/@rtk-query/codegen-openapi@4aaa709.tgz -D

pnpm add https://pkg.pr.new/@rtk-query/codegen-openapi@4aaa709.tgz -D

bun add https://pkg.pr.new/@rtk-query/codegen-openapi@4aaa709.tgz -D

@rtk-query/graphql-request-base-query

npm i https://pkg.pr.new/@rtk-query/graphql-request-base-query@4aaa709 -D

yarn add https://pkg.pr.new/@rtk-query/graphql-request-base-query@4aaa709.tgz -D

pnpm add https://pkg.pr.new/@rtk-query/graphql-request-base-query@4aaa709.tgz -D

bun add https://pkg.pr.new/@rtk-query/graphql-request-base-query@4aaa709.tgz -D

@reduxjs/toolkit

npm i https://pkg.pr.new/@reduxjs/toolkit@4aaa709 -D

yarn add https://pkg.pr.new/@reduxjs/toolkit@4aaa709.tgz -D

pnpm add https://pkg.pr.new/@reduxjs/toolkit@4aaa709.tgz -D

bun add https://pkg.pr.new/@reduxjs/toolkit@4aaa709.tgz -D

commit: 4aaa709

[EskiMojo14]

the changes make sense to me, but i'd like a second pair of eyes on this