chore(deps): update dependency @reduxjs/toolkit to v2.9.1

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
@reduxjs/toolkit (source)	2.8.2 -> 2.9.1

---

Release Notes

reduxjs/redux-toolkit (@​reduxjs/toolkit)

v2.9.1

Compare Source

This bugfix release fixes how sorted entity adapters handle duplicate IDs, tweaks the TS types for RTKQ query state cache entries to improve how the data field is handled, and adds better cleanup for long-running listener middleware effects.

What's Changed

• fix(entityAdapter): ensure sorted addMany keeps first occurrence of duplicate ids by @​demyanm in #​5097
• fix(entityAdapter): ensure sorted setMany keeps just unique IDs in state.ids by @​demyanm in #​5107
• fix(types): ensure non-undefined data on isSuccess with exactOptionalPropertyTypes by @​CO0Ki3 in #​5088
• Allow executing effects that have become unsubscribed to be canceled by listenerMiddleware.clearListeners by @​chris-chambers in #​5102

Full Changelog: reduxjs/redux-toolkit@v2.9.0...v2.9.1

v2.9.0

Compare Source

This feature release rewrites RTK Query's internal subscription and polling systems and the useStableQueryArgs hook for better perf, adds automatic AbortSignal handling to requests still in progress when a cache entry is removed, fixes a bug with the transformResponse option for queries, adds a new builder.addAsyncThunk method, and fixes assorted other issues.

Changelog

RTK Query Performance Improvements

We had reports that RTK Query could get very slow when there were thousands of subscriptions to the same cache entry. After investigation, we found that the internal polling logic was attempting to recalculate the minimum polling time after every new subscription was added. This was highly inefficient, as most subscriptions don't change polling settings, and it required repeated O(n) iteration over the growing list of subscriptions. We've rewritten that logic to debounce the update check and ensure a max of one polling value update per tick for the entire API instance.

Related, while working on the request abort changes, testing showed that use of plain Records to hold subscription data was inefficient because we have to iterate keys to check size. We've rewritten the subscription handling internals to use Maps instead, as well as restructuring some additional checks around in-flight requests.

These two improvements drastically improved runtime perf for the thousands-of-subscriptions-one-cache-entry repro, eliminating RTK methods as visible hotspots in the perf profiles. It likely also improves perf for general usage as well.

We've also changed the implementation of our internal useStableQueryArgs hook to avoid calling serializeQueryArgs on its value, which can avoid potential perf issues when a query takes a very large object as its cache key.

[!NOTE]
The internal logic switched from serializing the query arg to doing reference checks on nested values. This means that if you are passing a non-POJO value in a query arg, such as useSomeQuery({a: new Set()}), and you have refetchOnMountOrArgChange enabled, this will now trigger refeteches each time as the Set references are now considered different based on equality instead of serialization.

Abort Signal Handling on Cleanup

We've had numerous requests over time for various forms of "abort in-progress requests when the data is no longer needed / params change / component unmounts / some expensive request is taking too long". This is a complex topic with multiple potential use cases, and our standard answer has been that we don't want to abort those requests - after all, cache entries default to staying in memory for 1 minute after the last subscription is removed, so RTKQ's cache can still be updated when the request completes. That also means that it doesn't make sense to abort a request "on unmount".

However, it does then make sense to abort an in-progress request if the cache entry itself is removed. Given that, we've updated our cache handling to automatically call the existing resPromise.abort() method in that case, triggering the AbortSignal attached to the baseQuery. The handling at that point depends on your app - fetchBaseQuery should handle that, a custom baseQuery or queryFn would need to listen to the AbortSignal.

We do have an open issue asking for further discussions of potential abort / cancelation use cases and would appreciate further feedback.

New Options

The builder callback used in createReducer and createSlice.extraReducers now has builder.addAsyncThunk available, which allows handling specific actions from a thunk in the same way that you could define a thunk inside createSlice.reducers:

        const slice = createSlice({
          name: 'counter',
          initialState: {
            loading: false,
            errored: false,
            value: 0,
          },
          reducers: {},
          extraReducers: (builder) =>
            builder.addAsyncThunk(asyncThunk, {
              pending(state) {
                state.loading = true
              },
              fulfilled(state, action) {
                state.value = action.payload
              },
              rejected(state) {
                state.errored = true
              },
              settled(state) {
                state.loading = false
              },
            }),
        })

createApi and individual endpoint definitions now accept a skipSchemaValidation option with an array of schema types to skip, or true to skip validation entirely (in case you want to use a schema for its types, but the actual validation is expensive).

Bug Fixes

The infinite query implementation accidentally changed the query internals to always run transformResponse if provided, including if you were using upsertQueryData(), which then broke. It's been fixed to only run on an actual query request.

The internal changes to the structure of the state.api.provided structure broke our handling of extractRehydrationInfo - we've updated that to handle the changed structure.

The infinite query status fields like hasNextPage are now a looser type of boolean initially, rather than strictly false.

TS Types

We now export Immer's WritableDraft type to fix another non-portable types issue.

We've added an api.endpoints.myEndpoint.types.RawResultType types-only field to match the other available fields.

What's Changed

• Add RawResultType as a type-only property on endpoints by @​EskiMojo14 in #​5037
• allow passing an array of specific schemas to skip by @​EskiMojo14 in #​5042
• fix(types): re-exporting WritableDraft from immer by @​marinsokol5 in #​5015
• Remove Serialisation from useStableQueryArgs by @​riqts in #​4996
• add addAsyncThunk method to reducer map builder by @​EskiMojo14 in #​5007
• Only run transformResponse when a query is used by @​markerikson in #​5049
• Assorted bugfixes for 2.8.3 by @​markerikson in #​5060
• Abort pending requests if the cache entry is removed by @​markerikson in #​5061
• Update TS CI config by @​markerikson in #​5065
• Rewrite subscription handling and polling calculations for better perf by @​markerikson in #​5064

Full Changelog: reduxjs/redux-toolkit@v2.8.2...v2.9.0

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[changeset-bot]

⚠️ No Changeset found

Latest commit: fb01521

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[nx-cloud]

View your CI Pipeline Execution ↗ for commit fb01521

Command	Status	Duration	Result
nx run-many -t build	✅ Succeeded	<1s	View ↗
nx affected -t build typecheck lint test e2e-ci	✅ Succeeded	1m 7s	View ↗
nx-cloud record -- nx format:check	✅ Succeeded	1s	View ↗

---

☁️ Nx Cloud last updated this comment at 2025-10-21 22:33:04 UTC

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 18.75%. Comparing base (6b110df) to head (fb01521).

❌ Your project status has failed because the head coverage (18.75%) is below the target coverage (40.00%). You can increase the head coverage or adjust the target coverage.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #397   +/-   ##
=======================================
  Coverage   18.75%   18.75%           
=======================================
  Files         138      138           
  Lines       27368    27368           
  Branches      951      951           
=======================================
  Hits         5132     5132           
  Misses      22236    22236           

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[github-actions]

Deployed 6e60d19 to https://ForgeRock.github.io/ping-javascript-sdk/pr-397/6e60d1951bbd3b6a6d4122b6087db43ec897e715 branch gh-pages in ForgeRock/ping-javascript-sdk

[github-actions]

📦 Bundle Size Analysis

📦 Bundle Size Analysis

🆕 New Packages

🆕 @forgerock/device-client - 9.2 KB (new)
🆕 @forgerock/oidc-client - 23.0 KB (new)
🆕 @forgerock/protect - 150.1 KB (new)
🆕 @forgerock/sdk-utilities - 7.5 KB (new)
🆕 @forgerock/journey-client - 0.0 KB (new)
🆕 @forgerock/journey-client - 82.0 KB (new)
🆕 @forgerock/sdk-types - 8.0 KB (new)
🆕 @forgerock/storage - 1.4 KB (new)
🆕 @forgerock/sdk-logger - 1.6 KB (new)
🆕 @forgerock/iframe-manager - 2.4 KB (new)
🆕 @forgerock/sdk-request-middleware - 4.4 KB (new)
🆕 @forgerock/sdk-oidc - 2.5 KB (new)
🆕 @forgerock/davinci-client - 34.5 KB (new)

---

13 packages analyzed • Baseline from latest main build

Legend

🆕 New package
🔺 Size increased
🔻 Size decreased
➖ No change

ℹ️ How bundle sizes are calculated

• Current Size: Total gzipped size of all files in the package's dist directory
• Baseline: Comparison against the latest build from the main branch
• Files included: All build outputs except source maps and TypeScript build cache
• Exclusions: .map, .tsbuildinfo, and .d.ts.map files

---

_{🔄 Updated automatically on each push to this PR}

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[nx-cloud]

Nx Cloud has identified a possible root cause for your failed CI:

The task failure is classified as 'flaky_task' based on the following analysis:

PR Changes Analysis:
The pull request only modifies pnpm-lock.yaml, updating @reduxjs/toolkit from version 2.8.2 to 2.9.1, along with transitive dependency updates including @jridgewell/trace-mapping, detect-libc, loader-runner, node-abi, schema-utils, semver, tapable, and tar-fs. These are infrastructure-level dependency updates that do not modify application code, business logic, or test behavior.

Failure Analysis:
Both failing tests follow the same pattern:

1. Navigate to a page with a specific DaVinci flow
2. Fill in username and password fields
3. Click the "Sign On" button
4. Expect to see a risk blocking message ("Sorry Bot, we cannot let you in this time." or "You were blocked by PingOne Risk")
5. Both tests fail because the expected blocking message never appears within the 5-second timeout

Root Cause:
The test failures are caused by the PingOne Risk/Protect service not blocking the test user as expected. This is an external service behavior issue, not related to the dependency updates in the PR. The Redux Toolkit version bump and related transitive dependency updates do not affect:

• The Playwright test execution logic
• The risk assessment service integration
• The UI rendering of blocking messages
• The authentication flow behavior

The tests are dependent on an external risk assessment service properly flagging and blocking the test user, which appears to be failing intermittently or not functioning as expected in this test environment. This represents a flaky test scenario where the test outcome depends on external service behavior rather than the code changes in the PR.

No code changes are required because the dependency updates are not the source of the test failures. The issue lies with the test environment's integration with the PingOne Risk/Protect service.

A code change would likely not resolve this issue, so no action was taken.

View in Nx Cloud ↗

_{🎓 To learn more about Self Healing CI, please visit nx.dev}

[pkg-pr-new]

Open in StackBlitz

@forgerock/davinci-client

pnpm add https://pkg.pr.new/ForgeRock/ping-javascript-sdk/@forgerock/davinci-client@397

@forgerock/oidc-client

pnpm add https://pkg.pr.new/ForgeRock/ping-javascript-sdk/@forgerock/oidc-client@397

@forgerock/protect

pnpm add https://pkg.pr.new/ForgeRock/ping-javascript-sdk/@forgerock/protect@397

@forgerock/sdk-types

pnpm add https://pkg.pr.new/ForgeRock/ping-javascript-sdk/@forgerock/sdk-types@397

@forgerock/sdk-utilities

pnpm add https://pkg.pr.new/ForgeRock/ping-javascript-sdk/@forgerock/sdk-utilities@397

@forgerock/iframe-manager

pnpm add https://pkg.pr.new/ForgeRock/ping-javascript-sdk/@forgerock/iframe-manager@397

@forgerock/sdk-logger

pnpm add https://pkg.pr.new/ForgeRock/ping-javascript-sdk/@forgerock/sdk-logger@397

@forgerock/sdk-oidc

pnpm add https://pkg.pr.new/ForgeRock/ping-javascript-sdk/@forgerock/sdk-oidc@397

@forgerock/sdk-request-middleware

pnpm add https://pkg.pr.new/ForgeRock/ping-javascript-sdk/@forgerock/sdk-request-middleware@397

@forgerock/storage

pnpm add https://pkg.pr.new/ForgeRock/ping-javascript-sdk/@forgerock/storage@397

commit: fb01521