Repository navigation
[0.88] Fix cache-key test failing on release branches #1416
Description
Target Branch
0.88
Link to commit or PR to be picked
- Fix cache-key test on release branches react/react-native#58546 (
6e862f9a781onmain, D120209439) - Applied to
0.88-stableasad7b17d8eef
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 contentsThe 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
github-actions commentedon Sep 16, 2026
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
TurboModule.getEnforcingfunction is throwing an unexpected assertion error.react-native-macosis not behaving as expected or is regressingReactRootView.java) if it is causing a breaking change for the React Native ecosystem.❌ Which Pick Requests we don't accept
ℹ️ What makes for a good Pick Request
In order for your Pick Request to be considered, please do the following:
main, or one PR against the release branch.fabriziocucci commentedon Sep 16, 2026
Picked manually into
0.88-stableasad7b17d8eef, and forward-ported tomainas6e862f9a781(#58546).