Validate React on Rails 17 RC 9

[justin808]

Summary

• Update react_on_rails and react-on-rails from RC6 to RC9.
• Keep unrelated dependencies unchanged.

Validation

• Conservative Bundler update, Yarn install, and bundle check
• Exact gem/npm version checks
• Rails tests and JavaScript build
• Production client/server asset precompile
• React on Rails doctor: 39 passed, 0 errors
• git diff --check
• Independent codex review --commit a33a6c574c105ea2cebb7989df779e49c798717b: clean

The /hello_world MiniRacer SSR smoke returns 500 because MessageChannel is unavailable. The same failure reproduces on the RC6 base, so it is a pre-existing runtime limitation rather than an RC9 regression.

Lockfile audit

Only the target dependency version, source, and integrity changed. No transitive dependency, platform, native/precompiled, source-build, or build-time dependency changed.

QA Evidence

• QA lane: codex-rc9-qa
• Scope checked: exact dependency diff, builds, doctor, Rails tests, and RC6 baseline comparison
• Tested at: a33a6c574c105ea2cebb7989df779e49c798717b
• Automated checks: listed above
• Manual checks: bounded RC6-vs-RC9 MiniRacer SSR comparison
• Findings: pre-existing MiniRacer MessageChannel limitation; no RC9 regression
• QA required: yes
• QA required rationale: release-candidate migration example update
• QA lane status: satisfied
• Release-blocking status: clear for RC9 delta
• Process-gap disposition: park

Confidence note: High for the scoped RC9 delta; the SSR limitation is independently baseline-reproduced. Merge authority remains with maintainers.

[coderabbitai]

Warning

Review limit reached

@justin808, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 5 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 008bc9b5-eaf2-476a-ad75-301b3b70bd7c

📥 Commits

Reviewing files that changed from the base of the PR and between 1e0b734 and a33a6c5.

⛔ Files ignored due to path filters (2)

• Gemfile.lock is excluded by !**/*.lock
• yarn.lock is excluded by !**/yarn.lock, !**/*.lock

📒 Files selected for processing (2)

• Gemfile
• package.json

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch jg-codex/ror-17-rc9

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[claude]

Minor suggestion (non-blocking): this jumps three release candidates (rc.6 → rc.9) in one step. Since react_on_rails is still pre-1.0 and RC APIs can shift between candidates, it'd be worth a quick skim of the upstream CHANGELOG for rc.7–rc.9 to confirm there are no relevant breaking changes beyond what's already been validated here (doctor/tests/build all green per the PR description).

[claude]

Review: Validate React on Rails 17 RC9

Overview

Clean, minimal dependency bump: react_on_rails (Gemfile/Gemfile.lock) and react-on-rails (package.json/yarn.lock) from 17.0.0.rc.6 → 17.0.0.rc.9. 8 additions / 8 deletions across 4 files, no other code touched.

Correctness

• ✅ Version bump is consistent across all four files (Gemfile, Gemfile.lock, package.json, yarn.lock) — no mismatched pins.
• ✅ Lockfile diffs are scoped exactly to the target dependency (verified Gemfile.lock and yarn.lock diffs directly) — no unexpected transitive dependency churn, consistent with the "Lockfile audit" claim in the PR description.
• ✅ No stray rc.6/rc-6 references left anywhere else in the repo.
• ✅ yarn.lock integrity hash was updated alongside the resolved URL, as expected for a registry-fetched package bump.

Code quality / style

• Nothing to flag — this is about as low-risk a diff as a dependency bump can be, and the PR description documents thorough validation (bundle/yarn checks, Rails tests, JS build, production asset precompile, react_on_rails doctor, and an independent codex review).

Risks / things worth double-checking

• This skips two intermediate release candidates (rc.7, rc.8). Since react_on_rails 17 is still pre-1.0, it'd be worth a quick skim of the upstream CHANGELOG for rc.7–rc.9 to confirm nothing else changed behaviorally beyond what's already been exercised by the test/build/doctor validation described in the PR (left as an inline comment on the Gemfile line).
• The PR notes the /hello_world MiniRacer SSR smoke test returns 500 due to MessageChannel being unavailable, but confirms this reproduces on the RC6 baseline too — good practice to explicitly rule this out as a regression rather than silently ignoring it.

Security

• No security concerns. This is a same-source, same-major-version upgrade with an updated integrity hash; no new dependencies or install scripts introduced.

Test coverage

• No new tests needed for a version bump; existing test suite + react_on_rails doctor + asset precompile checks provide adequate coverage per the PR description.

Overall: Looks good to merge — well-scoped, well-documented, and low risk.

[greptile-apps]

Greptile Summary

This PR updates the React on Rails example to RC9. The main changes are:

• react_on_rails gem pinned to 17.0.0.rc.9.
• react-on-rails npm package pinned to 17.0.0-rc.9.
• Bundler and Yarn lockfiles updated for those package versions.

Confidence Score: 5/5

This looks safe to merge after checking the vendored server runtime alignment.

• The dependency bump is aligned across Ruby and JavaScript packages.
• The lockfile changes appear limited to the target packages.
• The only follow-up is confirming the checked-in server runtime still matches the RC9 server-rendering contract.

package.json

Important Files Changed

Filename	Overview
Gemfile	Updates the Ruby react_on_rails pin from RC6 to RC9.
Gemfile.lock	Updates the resolved react_on_rails gem version while keeping the visible dependency set unchanged.
package.json	Updates the JavaScript react-on-rails pin from RC6 to RC9.
yarn.lock	Updates the resolved react-on-rails tarball URL and integrity for RC9.

_{Reviews (1): Last reviewed commit: "Bump React on Rails to 17.0.0-rc.9" | Re-trigger Greptile}

[greptile-apps]

Vendored Server Runtime May Lag

The npm package is upgraded to 17.0.0-rc.9, but the repository’s server entry still imports a vendored react-server.js file that was not changed in this PR. If that vendored runtime was generated from the older RC and RC9 expects a different server-rendering protocol, any prerender: true page can fail during SSR or render with mismatched client/server behavior.