Skip to content

[0.88] Fix cache-key test failing on release branches #1416

Closed
Closed
[0.88] Fix cache-key test failing on release branches#1416
Labels
Type Pick RequestPick requests to include commits inside a React Native release

Description

@fabriziocucci
fabriziocucci
opened on Sep 16, 2026

Target Branch

0.88

Link to commit or PR to be picked

Description

Bookkeeping record. Already applied to both 0.88-stable and main, so there is nothing to action. Filing it so the 0.88 list is complete.

The problem

test_js failed on every 0.88-stable run, on both Node versions, on a single assertion in packages/react-native-babel-preset/src/__tests__/cache-key-test.js:

Test Suites: 1 failed, 229 passed, 230 total
Tests:       1 failed, 1 skipped, 6026 passed, 6028 total

getCacheKey short-circuits for published releases:

if (!packageVersion.endsWith('-main')) {
  // Assume the integrity of package contents for published npm releases.
  cacheKey = packageVersion;
  return cacheKey;
}
// only past here does it hash package contents

The test called it twice with different package contents and asserted the keys differ. On a release branch the version is 0.88.0-rc.x, which does not end in -main, so both calls return the same version string and .not.toBe cannot pass. The test's own name says it: "cache key includes package metadata for main builds". It asserted main-only behaviour with no version guard.

Why 0.88 and not earlier

The test was added by #58251 (9c6efa25c1b) on 2026-09-02, five days before the 0.88 branch cut. It does not exist on 0.87-stable or earlier, so 0.88 is the first release branch to inherit it. It has been red since 0.88.0-rc.0.

This is not "how release branches are". It is a test bug that would have hit 0.89 too, the moment its version stopped ending in -main.

The fix

Assert the property that actually holds for each case, rather than skipping:

const {version: packageVersion} = require('../../package.json');

if (packageVersion.endsWith('-main')) {
  test('cache key includes package metadata for main builds', () => { ... });
} else {
  test('cache key is the package version for published releases', () => {
    expect(getCacheKey('{"dependency":"1.0.0"}')).toBe(packageVersion);
    expect(getCacheKey('{"dependency":"2.0.0"}')).toBe(packageVersion);
  });
}

This also adds coverage for the published-release path, which previously had none.

Both branches were verified, not just the one that runs on the release branch. On 0.88.0-rc.0 the release assertion passes; temporarily stamping the package version to 0.89.0-main makes the original main-build assertion pass. So neither branch is vacuously green.

Result

test_js is green on 0.88-stable. This was the last red job before rc1 was cut.

Unusual ordering worth noting: this was applied to 0.88-stable first to unblock rc1, then forward-ported to main, rather than landing on main and being picked. Both are now done, so 0.89 will inherit the fix at its branch cut.

Activity

  1. fabriziocucci
    added
    Type Pick RequestPick requests to include commits inside a React Native release
    on Sep 16, 2026
  2. github-project-automation
    moved this to Inbox in React Native 0.88 Releaseson Sep 16, 2026
  3. github-project-automation
    added this to React Native 0.88 Releaseson Sep 16, 2026

  4. github-actions commented on Sep 16, 2026

    @github-actions
    github-actionsbot
    on Sep 16, 2026 – with GitHub Actions

    Thank you for opening a new React Native Pick Request.

    These are the criteria we follow when accepting or rejecting a code change into a React Native release branch (source).

    If your Pick Request does not satisfy the criteria below, please close it as it will not be considered.

    ✅ Which Pick Requests we accept
    1. ✅ Fixes for regressions to core APIs. Examples:
      • A core component is behaving differently between versions 0.X and 0.X-1
      • The TurboModule.getEnforcing function is throwing an unexpected assertion error.
    2. ✅ Fixes to bugs in core React Native. Examples:
      • Breakpoints in React Native DevTools not working correctly in the debugger
      • Fast Refresh not working as expected
      • Metro bundler not starting properly or ignoring the configuration file
      • Buttons that are not clickable
    3. ✅ Fixes to APIs used by third-party libraries and out-of-tree platforms. Examples:
      • An API used by react-native-macos is not behaving as expected or is regressing
    4. ✅ Bump of patch version of dependencies. Example:
      • Bump Gradle from 8.11.0 to 8.11.1
    5. ✅ Fixes for low/high severity security vulnerabilities. Example:
      • Bump Gradle from 8.11.0 to 8.12.0 if there is a security vulnerability in 8.11 and no 8.11.x version contains the same fix.
    6. ✅ Fixes and reverts of accidental breaking changes. Example:
      • Reverting or fix-forwarding a Kotlin migration of a file (e.g. ReactRootView.java) if it is causing a breaking change for the React Native ecosystem.
    7. ✅ Performance improvements. Examples:
      • Fixing unnecessary re-renders in FlatList.
    8. ✅ Any Pick Request if the release is still in RC0 (after RC1, the previously listed criteria apply)
    ❌ Which Pick Requests we don't accept
    1. ❌ Any Pick Request that introduces a breaking change after RC1. Example:
      • A bugfix that contains a refactoring, resulting in changes to the public API of a class
    2. ❌ Any Pick Request that introduces a new feature after RC1. Example:
      • A commit that introduces a new API or a specific feature for a component.
    3. ❌ Bump of major or minor version of dependencies. Examples:
      • Bump Gradle from 8.11.0 to 8.12.0
      • Bump Gradle from 8.11.0 to 9.0.0
    4. ❌ Bump of a dependency to a pre-release version. Example:
      • Bump Gradle from 8.11.0 to 8.11.1-beta.1
    5. ❌ Any Pick Request that introduces changes to the React Native testing infrastructure after RC1. Examples:
      • Changes to GitHub Actions workflows to optimize them, even if they are on main.
      • Changes to the logic used to publish packages to NPM or Maven Central
    6. ❌ Pick Request composed of multiple commits that have several merge conflicts.
      • If your Pick Request is too complex to apply to the release branch, it will be rejected.
    7. ❌ Any non-critical improvement that landed on main.
      • These will generally ship in the following version unless they fit one of the criteria above.
    8. ❌ Any Pick Request considered a "nice to have".
      • Even one-line changes carry a risk of destabilizing and further delaying the release.
    ℹ️ What makes for a good Pick Request

    In order for your Pick Request to be considered, please do the following:

    • ℹ️ Limit your Pick Request to one commit from main, or one PR against the release branch.
    • ℹ️ Include a clear explanation of why your Pick Request should be considered, ideally referencing one of the criteria above.
    • ℹ️ Target only one minor version of React Native (e.g. [0.76]). To have your Pick Request applied to more versions, please open separate Pick Requests.

  5. fabriziocucci commented on Sep 16, 2026

    @fabriziocucci
    fabriziocucci
    on Sep 16, 2026
    CollaboratorAuthor

    Picked manually into 0.88-stable as ad7b17d8eef, and forward-ported to main as 6e862f9a781 (#58546).

  6. fabriziocucci
    closed this as completedon Sep 16, 2026
  7. github-project-automation
    moved this from Inbox to Done / Picked in React Native 0.88 Releaseson Sep 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type Pick RequestPick requests to include commits inside a React Native release

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions