Skip to content

[Snyk] Upgrade @reduxjs/toolkit from 2.2.7 to 2.9.0 #188

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

[Snyk] Upgrade @reduxjs/toolkit from 2.2.7 to 2.9.0 #188

wants to merge 1 commit into from

Conversation

graymalkin77
Copy link

snyk-top-banner

Snyk has created this PR to upgrade @reduxjs/toolkit from 2.2.7 to 2.9.0.

ℹ️ Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

  • The recommended version is 12 versions ahead of your current version.

  • The recommended version was released a month ago.

Release notes
Package name: @reduxjs/toolkit
  • 2.9.0 - 2025-09-03

    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

    Full Changelog: v2.8.2...v2.9.0

  • 2.8.2 - 2025-05-14

    This bugfix release fixes a bundle size regression in RTK Query from the build and packaging changes in v2.8.0.

    If you're using v2.8.0 or v2.8.1, please upgrade to v2.8.2 right away to resolve that bundle size issue!

    Changelog

    RTK Query Bundle Size

    In v2.8.0, we reworked our packaging setup to better support React Native. While there weren't many meaningful code changes, we did alter our bundling build config file. In the process, we lost the config options to externalize the @ reduxjs/toolkit core when building the RTK Query nested entry points. This resulted in a regression where the RTK core code also got bundled directly into the RTK Query artifacts, resulting in a significant size increase.

    This release fixes the build config and restores the previous RTKQ build artifact sizes.

    What's Changed

    Full Changelog: v2.8.1...v2.8.2

  • 2.8.1 - 2025-05-08

    This bugfix release makes an additional update to the package config to fix a regression that happened with Jest and jest-environment-jsdom.

    Caution

    This release had a bundle size regression. Please update to v2.8.2 to resolve that issue.

    Changes

    More Package Updates

    After releasing v2.8.0, we got reports that Jest tests were breaking. After investigation we concluded that jest-environment-jsdom was looking at the new browser package exports condition we'd added to better support JSPM, finding an ESM file containing the export keyword, and erroring because it doesn't support ES modules correctly.

    #4971 (comment) listed several viable workarounds, but this is enough of an issue we wanted to fix it directly. We've tweaked the package exports setup again, and it appears to resolve the issue with Jest.

    What's Changed

    Full Changelog: v2.8.0...v2.8.1

  • 2.8.0 - 2025-05-06

    This feature release improves React Native compatibility by updating our package exports definitions, and adds queryArg as an additional parameter to infinite query page param functions.

    Caution

    This release had a bundle size regression, as well as a breakage with jest-environment-jsdom. Please update to v2.8.2 to resolve those issues.

    Changelog

    Package Exports and React Native Compatibility

    Expo and the Metro bundler have been adding improved support for the exports field in package.json files, but those changes started printing warnings due to how some of our package definitions were configured.

    We've reworked the package definitions (again!), and this should be resolved now.

    Infinite Query Page Params

    The signature for the getNext/PreviousPageParam functions has been:

    (
    lastPage: DataType,
    allPages: Array<DataType>,
    lastPageParam: PageParam,
    allPageParams: Array<PageParam>,
  ) => PageParam | undefined | null

    This came directly from React Query's API and implementation.

    We've had some requests to make the endpoint's queryArg available in page param functions. For React Query, that isn't necessary because the callbacks are defined inline when you call the useInfiniteQuery hook, so you've already got the query arg available in scope and can use it. Since RTK Query defines these callbacks as part of the endpoint definition, the query arg isn't in scope.

    We've added queryArg as an additional 5th parameter to these functions in case it's needed.

    Other Changes

    We've made a few assorted docs updates, including replacing the search implementation to now use a local index generated on build (which should be more reliable and also has a nicer results list uI), and fixing some long-standing minor docs issues.

    What's Changed

    Full Changelog: v2.7.0...v2.8.0

  • 2.7.0 - 2025-04-16

    RTK has hit Stage 2.7! 🤣 This feature release adds support for Standard Schema validation in RTK Query endpoints, fixes several issues with infinite queries, improves perf when infinite queries provide tags, adds a dev-mode check for duplicate middleware, and improves reference stability in slice selectors and infinite query hooks.

    Changelog

    Standard Schema Validation for RTK Query

    Apps often need to validate responses from the server, both to ensure the data is correct, and to help enforce that the data matches the expected TS types. This is typically done with schema libraries such as Zod, Valibot, and Arktype. Because of the similarities in usage APIs, those libraries and others now support a common API definition called Standard Schema, allowing you to plug your chosen validation library in anywhere Standard Schema is supported.

    RTK Query now supports using Standard Schema to validate query args, responses, and errors. If schemas are provided, the validations will be run and errors thrown if the data is invalid. Additionally, providing a schema allows TS inference for that type as well, allowing you to omit generic types from the endpoint.

    Schema usage is per-endpoint, and can look like this:

    import { createApi, fetchBaseQuery } from '@ reduxjs/toolkit/query/react'
    import * as v from 'valibot'

    const postSchema = v.object({
    id: v.number(),
    name: v.string(),
    })
    type Post = v.InferOutput<typeof postSchema>

    const api = createApi({
    baseQuery: fetchBaseQuery({ baseUrl: '/' }),
    endpoints: (build) => ({
    getPost: build.query({
    // infer arg from here
    query: ({ id }: { id: number }) => /post/<span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">id</span><span class="pl-kos">}</span></span>,
    // infer result from here
    responseSchema: postSchema,
    }),
    getTransformedPost: build.query({
    // infer arg from here
    query: ({ id }: { id: number }) => /post/<span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">id</span><span class="pl-kos">}</span></span>,
    // infer untransformed result from here
    rawResponseSchema: postSchema,
    // infer transformed result from here
    transformResponse: (response) => ({
    ...response,
    published_at: new Date(response.published_at),
    }),
    }),
    }),
    })

    If desired, you can also configure schema error handling with the catchSchemaFailure option. You can also disable actual runtime validation with skipSchemaValidation (primarily useful for cases when payloads may be large and expensive to validate, but you still want to benefit from the TS type inference).

    See the "Schema Validation" docs section in the createApi reference and the usage guide sections on queries, infinite queries, and mutations, for more details.

    Infinite Query Fixes

    This release fixes several reported issue with infinite queries:

    • The lifecycleApi.updateCachedData method is now correctly available
    • The skip option now correctly works for infinite query hooks
    • Infinite query fulfilled actions now include the meta field from the base query (such as {request, response}). For cases where multiple pages are being refetched, this will be the meta from the last page fetched.
    • useInfiniteQuerySubscription now returns stable references for refetch and the fetchNext/PreviousPage methods

    upsertQueryEntries, Tags Performance and API State Structure

    We recently published a fix to actually process per-endpoint providedTags when using upsertQueryEntries. However, this exposed a performance issue - the internal tag handling logic was doing repeated O(n) iterations over all endpoint+tag entries in order to clear out existing references to that cache key. In cases where hundreds or thousands of cache entries were being inserted, this became extremely expensive.

    We've restructured the state.api.provided data structure to handle reverse-mapping between tags and cache keys, which drastically improves performance in this case. However, it's worth noting that this is a change to that state structure. This shouldn't affect apps, because the RTKQ state is intended to be treated as a black box and not generally directly accessed by user app code. However, it's possible someone may have depended on that specific state structure when writing a custom selector, in which case this would break. An actual example of this is the Redux DevTools RTKQ panel, which iterates the tags data while displaying cache entries. That did break with this change. Prior to releasing RTK 2.7,we released Redux DevTools 3.2.10, which includes support for both the old and new state.api.provided definitions.

    TS Support Matrix Updates

    Following with the DefinitelyTyped support matrix, we've officially dropped support for TS 5.0, and currently support TS 5.1 - 5.8. (RTK likely still works with 5.0, but we no longer test against that in CI.)

    Duplicate Middleware Dev Checks

    configureStore now checks the final middleware array for duplicate middleware references. This will catch cases such as accidentally adding the same RTKQ API middleware twice (such as adding baseApi.middleware and injectedApi.middlweware - these are actually the same object and same middleware).

    Unlike the other dev-mode checks, this is part of configureStore itself, not getDefaultMiddleware().

    This can be configured via the new duplicateMiddlewareCheck option.

    Other Changes

    createEntityAdapter now correctly handles adding an item and then applying multiple updates to it.

    The generated combineSlices selectors will now return the same placeholder initial state reference for a given slice, rather than returning a new initial state reference every time.

    useQuery hooks should now correctly refetch after dispatching resetApiState.

    What's Changed

    Full Changelog: v2.6.1...v2.7.0

  • 2.6.1 - 2025-03-07

    This bugfix release fixes several assorted types issues with the initial infinite query feature release, and adds support for an optional signal argument to createAsyncThunk.

    Changelog

    Infinite Query Fixes

    We've fixed several types issues that were reported with infinite queries after the 2.6.0 release:

    • matchFulfilled and providesTags now get the correct response types
    • We've added pre-typed Type* types to represent infinite queries, similar to the existing pre-defined types for queries and mutations
    • selectCachedArgsForQuery now supports fetching args for infinite query endpoints
    • We fixed some TS type portability issues with infinite queries that caused errors when generating TS declarations
    • useInfiniteQueryState/Subscription now correctly expect just the query arg, not the combined {queryArg, pageParam} object

    Other Improvements

    createAsyncThunk now accepts an optional {signal} argument. If provided, the internal AbortSignal handling will tie into that signal.

    upsertQueryEntries now correctly generates provided tags for upserted cache entries.

    What's Changed

    Full Changelog: v2.6.0...v2.6.1

  • 2.6.0 - 2025-02-23

    This feature release adds infinite query support to RTK Query.

    Changelog

    RTK Query Infinite Query support

    Since we first released RTK Query in 2021, we've had users asking us to add support for "infinite queries" - the ability to keep fetching additional pages of data for a given endpoint. It's been by far our most requested feature. Until recently, our answer was that we felt there were too many use cases to support with a single API design approach.

    Last year, we revisited this concept and concluded that the best approach was to mimic the flexible infinite query API design from React Query. We had additional discussions with @ TkDodo , who described the rationale and implementation approach and encouraged us to use their API design, and @ riqts provided an initial implementation on top of RTKQ's existing internals.

    We're excited to announce that this release officially adds full infinite query endpoint support to RTK Query!

    Using Infinite Queries

    As with React Query, the API design is based around "page param" values that act as the query arguments for fetching a specific page for the given cache entry.

    Infinite queries are defined with a new build.infiniteQuery() endpoint type. It accepts all of the same options as normal query endpoints, but also needs an additional infiniteQueryOptions field that specifies the infinite query behaviors. With TypeScript, you must supply 3 generic arguments: build.infiniteQuery<ResultType, QueryArg, PageParam>, where ResultType is the contents of a single page, QueryArg is the type passed in as the cache key, and PageParam is the value used to request a specific page.

    The endpoint must define an initialPageParam value that will be used as the default (and can be overridden if desired). It also needs a getNextPageParam callback that will calculate the params for each page based on the existing values, and optionally a getPreviousPageParam callback if reverse fetching is needed. Finally, a maxPages option can be provided to limit the entry cache size.

    The query and queryFn methods now receive a {queryArg, pageParam} object, instead of just the queryArg.

    For the cache entries and hooks, the data field is now an object like {pages: ResultType[], pageParams: PageParam[]>. This gives you flexibility in how you use the data for rendering.

    const pokemonApi = createApi({
  baseQuery: fetchBaseQuery({ baseUrl: 'https://example.com/pokemon' }),
  endpoints: (build) => ({
    // 3 TS generics: page contents, query arg, page param
    getInfinitePokemonWithMax: build.infiniteQuery<Pokemon[], string, number>({
      infiniteQueryOptions: {
        // Must provide a default initial page param value
        initialPageParam: 1,
        // Optionally limit the number of cached pages
        maxPages: 3,
        // Must provide a `getNextPageParam` function
        getNextPageParam: (lastPage, allPages, lastPageParam, allPageParams) =>
          lastPageParam + 1,
        // Optionally provide a `getPreviousPageParam` function
        getPreviousPageParam: (
          firstPage,
          allPages,
          firstPageParam,
          allPageParams,
        ) => {
          return firstPageParam > 0 ? firstPageParam - 1 : undefined
        },
      },
      // The `query` function receives `{queryArg, pageParam}` as its argument
      query({ queryArg, pageParam }) {
        return `/type/${queryArg}?page=${pageParam}`
      },
    }),
  }),...

@snyk-bot
fix: upgrade @reduxjs/toolkit from 2.2.7 to 2.9.0
e797789 
Snyk has created this PR to upgrade @reduxjs/toolkit from 2.2.7 to 2.9.0.

See this package in npm:
@reduxjs/toolkit

See this project in Snyk:
https://app.snyk.io/org/cognigy-gmbh/project/92bd593a-b4bf-439d-8778-29e930fdd262?utm_source=github&utm_medium=referral&page=upgrade-pr
@Copilot Copilot AI review requested due to automatic review settings September 30, 2025 04:15
Copilot
Copilot AI reviewed Sep 30, 2025
View reviewed changes
Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR upgrades the @reduxjs/toolkit package from version 2.2.7 to 2.9.0, bringing the project up to date with the latest features and improvements. The upgrade spans 12 versions and includes significant performance improvements, new features like infinite query support and Standard Schema validation, and various bug fixes.

Key changes included in this upgrade:

  • Performance improvements to RTK Query subscription and polling systems
  • Addition of infinite query support for RTK Query
  • New Standard Schema validation support for endpoints
  • Automatic AbortSignal handling for cache entry cleanup

Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.

@graymalkin77
Copy link
Author

graymalkin77 commented Sep 30, 2025 •
edited
Loading

🎉 Snyk checks have passed. No issues have been found so far.

✅ security/snyk check is complete. No issues have been found. (View Details)

✅ license/snyk check is complete. No issues have been found. (View Details)

✅ code/snyk check is complete. No issues have been found. (View Details)

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

Reviewers

Copilot code review Copilot Copilot left review comments

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@graymalkin77 @snyk-bot