Skip to content

Pin Pro RSC runtime to stable 19.0.5#3990

Closed
justin808 wants to merge 19 commits into
mainfrom
codex/3965-rsc-pin-range
Closed

Pin Pro RSC runtime to stable 19.0.5#3990
justin808 wants to merge 19 commits into
mainfrom
codex/3965-rsc-pin-range

Conversation

@justin808

@justin808 justin808 commented Jun 13, 2026

Copy link
Copy Markdown
Member

Summary

  • Pin the Pro RSC install path to stable react-on-rails-rsc@19.0.5 after confirming pnpm view react-on-rails-rsc version returns 19.0.5.
  • Replace the broad Pro optional peer wildcard with ~19.0.5 || 19.0.5-rc.6 || 19.0.5-rc.7, keeping the coordinated rc.6/rc.7 upgrade warning path explicit while preventing unvalidated 19.1+ RSC lines.
  • Update generator messages, Pro RSC docs, lockfiles, generated llms-full output, and peer-compatibility guardrail tests so the Ruby generator pin, Pro peer exceptions, and node-renderer runtime checks stay aligned.

Issue Dispositions

Agent Merge Confidence

Mode: accelerated-rc (#3823)
Current head SHA: 5805fa8
Score: 9/10
Auto-merge recommendation: yes
Affected areas: Pro RSC peer compatibility, generator RSC dependency pin, RSC upgrade docs, generated LLM references, lockfile/package metadata
CI detector: script/ci-changes-detector origin/main -> broad package/Pro/RSC/docs coverage selected; labels full-ci, benchmark are present and appropriate.
Validation run:

  • pnpm view react-on-rails-rsc version -> 19.0.5.
  • pnpm install --lockfile-only --ignore-scripts -> passed.
  • node script/generate-llms-full.mjs -> regenerated llms-full.txt and llms-full-pro.txt under the 2048 KiB split threshold.
  • node script/generate-llms-full.mjs --check -> passed.
  • bash script/generate-llms-full-test.bash -> passed, 5 tests.
  • pnpm --dir packages/react-on-rails-pro-node-renderer exec jest tests/checkRscPeerCompatibility.test.ts --runInBand -> passed, 21 tests, including current-head review fix 5805fa81b.
  • pnpm --dir packages/react-on-rails-pro-node-renderer run type-check -> passed, including current-head review fix 5805fa81b.
  • pnpm --dir packages/react-on-rails-pro-node-renderer exec prettier --check packages/react-on-rails-pro-node-renderer/tests/checkRscPeerCompatibility.test.ts -> passed for current-head review fix 5805fa81b.
  • (cd react_on_rails && bundle exec rspec spec/react_on_rails/generators/js_dependency_manager_spec.rb spec/react_on_rails/generators/install_generator_spec.rb) -> passed, 608 examples, 0 failures.
  • (cd react_on_rails && BUNDLE_GEMFILE=../Gemfile bundle exec rubocop) -> passed, 218 files, no offenses.
  • pnpm run lint -> passed after pnpm install --ignore-scripts refreshed stale local node_modules from the committed lockfile.
  • pnpm start format.listDifferent -> passed.
  • script/check-docs-sidebar -> passed.
  • PATH=/tmp/lychee-v0.23.0:$PATH lychee --config .lychee.toml docs/pro/react-server-components/upgrading-existing-pro-app.md docs/pro/react-server-components/create-without-ssr.md docs/pro/react-server-components/rspack-compatibility.md -> passed.
  • git diff --check origin/main...HEAD and git diff --check -> passed.
  • Pre-commit and pre-push hooks passed for current head 5805fa81b34b348549e1f90f25ace652d4b83e1c.
    Review/check gate:
  • GitHub checks: complete for 5805fa81b34b348549e1f90f25ace652d4b83e1c; full gh pr checks 3990 shows all current-head checks passing or intentionally skipped by workflow selection. Passing coverage includes package JS tests, generator/unit specs, dummy app integration/e2e, Pro lint, builds, CodeQL, docs/link/sidebar checks, full benchmarks, claude-review, Cursor Bugbot, and CodeRabbit skipped.
  • Review threads: three current-head Claude threads were triaged as non-blocking before resolution: exporting the test-support interface is API ergonomics only, normalizing maintainer-authored allowlist entries with a leading v is defensive future-proofing only, and using a set comparison for semver-range prerelease order is a maintenance nit while the range/order is currently stable and tested. No unresolved non-trivial concerns remain.
  • Current-head reviewer verdicts: claude-review passed for 5805fa81b34b348549e1f90f25ace652d4b83e1c; Cursor Bugbot passed; CodeRabbit skipped its review by automation and reported no blocking status.
  • Stale reviewer verdicts, advisory only: earlier Claude/Greptile/Codex comments were handled by code/doc fixes where needed; remaining older priority findings are fixed, superseded, or non-blocking and are not cited as merge gates.
    Feedback triage:
  • Exact-save docs feedback: addressed for create-without-ssr.md, upgrading-existing-pro-app.md, and troubleshooting commands; generated llms-full-pro.txt is current.
  • Stale generated references: addressed by regenerating llms-full.txt and llms-full-pro.txt from the current generator.
  • Empty prerelease guidance assertion: addressed with non-empty guidance coverage and an explicit empty-allowlist message test.
  • Test mutation fragility: addressed with cleanup around the current mutation test plus cross-language/cross-package invariant coverage; the optional support parameter is used as a test seam and is not being promoted as public API in this PR.
  • Generator/runtime/peer range sync: addressed with Jest invariants for Ruby generator pin alignment, Pro peer prerelease exceptions, allowed prerelease stable-base alignment, and Pro package peer exceptions.
  • Current-head minor threads: waived as non-blocking for this release-critical stable-pin PR after inspection; they can be revisited in a future cleanup without changing runtime behavior.
  • Lockfile side-channel: pnpm install --lockfile-only --ignore-scripts also refreshed transitive acorn snapshot references from 8.15.0 to 8.16.0 under acorn-jsx, espree, jsdom, and terser. No direct manifest dependency was added for that drift.
    Labels: full-ci, benchmark. This branch changes Pro/RSC compatibility, generated docs, generator dependency behavior, package metadata, and lockfiles; broad CI plus benchmarks are appropriate.
    Known residual risk: Low. The remaining risk is normal dependency/lockfile-release surface risk; it is mitigated by local validation, full current-head CI, benchmarks, and current-head independent review checks.
    Finalized by: claude-review GitHub check for current head 5805fa81b34b348549e1f90f25ace652d4b83e1c (independent named check/app identity), with Cursor Bugbot also passing for the same head.

Current Readiness

Merge-ready under the accelerated-RC criteria: current-head local validation is complete, full GitHub checks and benchmarks are green or intentionally skipped, current-head review feedback is fixed or triaged above, and the release tracker identifies this stable RSC pin as the remaining final-only blocker path. Merge recommendation: squash merge now.


Note

Medium Risk
Touches Pro RSC dependency policy and startup peer validation, which can block or warn mis-versioned apps; scope is metadata/docs/runtime checks rather than core rendering logic.

Overview
Moves Pro RSC installs and docs from react-on-rails-rsc@19.0.5-rc.7 to stable 19.0.5: the Ruby generator pin, root/Pro/dummy package.json entries, lockfile, and Pro RSC upgrade guides (plus regenerated llms-full* output).

react-on-rails-pro no longer uses a wildcard optional peer for react-on-rails-rsc; it declares ~19.0.5 || ~19.2.0 plus explicit 19.0.5-rc.6 / 19.0.5-rc.7 exceptions so existing RC apps can still install while the node renderer nudges them to stable.

The Pro node renderer’s checkRscPeerCompatibility / RSC_PEER_SUPPORT now treat 19.0.5 as the recommended floor, allow only listed prereleases, error on other prereleases, and warn when an allowed RC matches the stable minimum; Jest specs assert the generator pin, Pro peer range, and runtime metadata stay in sync.

Reviewed by Cursor Bugbot for commit 0c90b7d. Bugbot is set up for automated code reviews on this repo. Configure here.

@coderabbitai

coderabbitai Bot commented Jun 13, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

  • @coderabbitai resume to resume automatic reviews.
  • @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

  • ▶️ Resume reviews
  • 🔍 Trigger review

Walkthrough

This PR promotes react-on-rails-rsc from 19.0.5-rc.7 to the stable 19.0.5 across package manifests, the Ruby generator, peer compatibility logic, and RSC documentation. Separately, it extends generate-llms-full.mjs to produce split llms-full-oss.txt and llms-full-pro.txt files above a size threshold, updating CI path filters and LLM routing docs accordingly.

Changes

RSC Stable Pin Promotion

Layer / File(s) Summary
RSC peer support config and compatibility logic
packages/react-on-rails-pro-node-renderer/src/shared/rscPeerSupport.ts, packages/react-on-rails-pro-node-renderer/src/shared/checkRscPeerCompatibility.ts
RSC_PEER_SUPPORT gains supportedMinor and allowedPrereleases for 19.0.5-rc.6/rc.7; compatibility check adds minor-line enforcement, prerelease allowlist validation, version-normalization helpers, and a distinct prereleaseWarnMessage.
RSC peer compatibility test coverage
packages/react-on-rails-pro-node-renderer/tests/checkRscPeerCompatibility.test.ts
Tests cover the new minor-line enforcement, prerelease allowlisting, OK stable cases (19.0.5/19.0.6), allowed/unlisted prerelease warnings and errors, and unsupported minor errors.
Package manifests and workspace pin
packages/react-on-rails-pro/package.json, package.json, react_on_rails_pro/spec/dummy/package.json
react-on-rails-pro peer narrows from "*" to ~19.0.5 || 19.0.5-rc.6 || 19.0.5-rc.7; devDependencies and the root workspace pin move from 19.0.5-rc.7 to 19.0.5; dummy app updated to match.
Ruby generator pin constant and message helpers
react_on_rails/lib/generators/react_on_rails/js_dependency_manager.rb
RSC_PACKAGE_VERSION_PIN changed to 19.0.5; rsc_stable_package_version_target removed; pin-info and failure-warning message helpers simplified.
Generator spec updates for RSC pin and messaging
react_on_rails/spec/react_on_rails/generators/js_dependency_manager_spec.rb, react_on_rails/spec/react_on_rails/generators/install_generator_spec.rb
Expectations updated for fallback install, pin constant, and pin message coverage; failure/raise-path assertions updated; prerelease-target expectations removed.
RSC docs and Pro README stable-pin guidance
CHANGELOG.md, packages/react-on-rails-pro/README.md, docs/pro/react-server-components/*
Install commands, prerequisite tables, Rspack-compatibility notes, and troubleshooting instructions updated from 19.0.5-rc.7 to 19.0.5. Pro README adds optional-peer and RC-upgrade guidance.

LLM Reference File Splitting

Layer / File(s) Summary
generate-llms-full.mjs split-mode implementation and test
script/generate-llms-full.mjs, script/generate-llms-full-test.bash
Script gains single/split generation modes: below threshold produces only llms-full.txt; above threshold produces a split index plus llms-full-oss.txt and llms-full-pro.txt. Adds generateReference, generateSplitIndex, generatedOutputs, and related helpers. New bash test asserts split output is generated and contains expected reference strings.
CI workflow path filters and check-llms-full trigger
.github/workflows/check-llms-full.yml, .github/workflows/benchmark.yml, .github/workflows/examples.yml, .github/workflows/gem-tests.yml, .github/workflows/integration-tests.yml, .github/workflows/lint-js-and-ruby.yml, .github/workflows/package-js-tests.yml, .github/workflows/precompile-check.yml, .github/workflows/pro-integration-tests.yml, .github/workflows/pro-test-package-and-gem.yml
All CI paths-ignore entries broadened from llms-full.txt to llms-full*.txt. check-llms-full.yml push/pull_request path includes extended to cover llms-full-oss.txt and llms-full-pro.txt.
LLM routing files and preamble docs
llms.txt, AGENTS_USER_GUIDE.md, docs/llms-full-preamble.md
llms.txt canonical entry points and AGENTS_USER_GUIDE.md fallback strategy reference the new split files. llms-full-preamble.md describes single-file vs split-index consumption and the 2048 KiB threshold policy.

Sequence Diagram(s)

No sequence diagrams apply to this PR. The RSC changes are config/validation updates, and the LLM generation change is an internal orchestration refactor with no new cross-component flows.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

  • shakacode/react_on_rails#3857: Modifies the same generator pin logic and react-on-rails-rsc RC pinning in js_dependency_manager.rb and related Pro metadata, making it a direct code-level predecessor.
  • shakacode/react_on_rails#3903: Introduced the script/generate-llms-full.mjs drift-guard and check-llms-full.yml workflow that this PR extends with split-file generation.
  • shakacode/react_on_rails#3831: Updated rscPeerSupport.ts and checkRscPeerCompatibility.ts in the same runtime version-check layer that this PR expands with minor-line enforcement and prerelease allowlisting.

Suggested labels

enhancement, documentation, P2

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title 'Pin Pro RSC runtime to stable 19.0.5' directly and clearly describes the main change: updating the react-on-rails-rsc dependency from prerelease to stable version 19.0.5.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch codex/3965-rsc-pin-range

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

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

@github-actions

github-actions Bot commented Jun 13, 2026

Copy link
Copy Markdown
Contributor

size-limit report 📦

Path Size
react-on-rails/client bundled (gzip) 61.41 KB (0%)
react-on-rails/client bundled (gzip) (time) 61.41 KB (0%)
react-on-rails/client bundled (brotli) 52.63 KB (0%)
react-on-rails/client bundled (brotli) (time) 52.63 KB (0%)
react-on-rails-pro/client bundled (gzip) 62.57 KB (0%)
react-on-rails-pro/client bundled (gzip) (time) 62.57 KB (0%)
react-on-rails-pro/client bundled (brotli) 53.69 KB (0%)
react-on-rails-pro/client bundled (brotli) (time) 53.69 KB (0%)
registerServerComponent/client bundled (gzip) 72.74 KB (+0.01% 🔺)
registerServerComponent/client bundled (gzip) (time) 72.74 KB (+0.01% 🔺)
registerServerComponent/client bundled (brotli) 62.56 KB (+0.05% 🔺)
registerServerComponent/client bundled (brotli) (time) 62.56 KB (+0.05% 🔺)
wrapServerComponentRenderer/client bundled (gzip) 66.08 KB (+0.01% 🔺)
wrapServerComponentRenderer/client bundled (gzip) (time) 66.08 KB (+0.01% 🔺)
wrapServerComponentRenderer/client bundled (brotli) 56.65 KB (0%)
wrapServerComponentRenderer/client bundled (brotli) (time) 56.65 KB (0%)

@claude

claude Bot commented Jun 13, 2026

Copy link
Copy Markdown
Contributor

Code Review

Overall: This is a clean and well-coordinated promotion from a prerelease RC to the stable react-on-rails-rsc@19.0.5. The validation checklist in the PR description is thorough. A few items worth discussing before merge:


Concerns

1. Peer dependency range is wider than the docs allow

packages/react-on-rails-pro/package.json declares:

"react-on-rails-rsc": "^19.0.5 || 19.0.5-rc.6 || 19.0.5-rc.7"

The caret (^) range admits any 19.x.x >= 19.0.5, including 19.1.0, 19.2.0, etc. The docs and README explicitly warn against advancing past React 19.0.x because the RSC bundler APIs can change. The peer range signals npm/pnpm/yarn that those versions are acceptable, which could mislead tooling or users who rely on npm ls to validate compatibility. ~19.0.5 (patch-only) would be tighter and more accurate.

The PR description calls this out as a residual risk and notes that runtime checks gate mismatches — that's a reasonable mitigation, but the peer metadata misaligning with the docs is a point of confusion worth resolving.

2. Incidental acorn version bump in lockfile

The lockfile updates include acorn@8.15.0acorn@8.16.0 across several snapshot entries (espree, jsdom, terser, acorn-jsx). These are unrelated to the RSC pin change and appear to be a transitive resolution update that got folded in during pnpm install. Worth confirming this was intentional — if not, isolating it from this PR would keep the diff focused.


Minor observations

3. Test coverage gap: only rc.6 is tested for the new prerelease-at-stable-floor warning

The new behavior (warn when the RSC version is a prerelease at the same tuple as recommendedMin) is tested with 19.0.5-rc.6 but not 19.0.5-rc.7 — the prior actual pin. Both should produce identical results, so this is low risk, but adding a test for rc.7 would close the gap.

4. Prerelease above recommendedMin silently passes

19.0.6-beta.1 would receive ok rather than warn because its parsed tuple [19,0,6] is strictly above [19,0,5], making sameTuple false. The comment says "prerelease at the same 19.0.5 tuple" so this appears intentional, but it could surprise a future developer. A small inline comment on the warn condition explaining that higher-tuple prereleases are out of scope for this heuristic would help.

5. Test for rsc_dependency_pin_messages no longer covers hypothetical future prerelease pins

The old spec stubbed RSC_PACKAGE_VERSION_PIN = "19.1.0-rc.1" to verify derived-stable message logic. The new spec only tests the current pin value. Since rsc_stable_package_version_target was removed, the deletion is correct — but if we ever return to a prerelease pin, there is no test harness ensuring the warning messages remain coherent.


What is done well

  • The peer range ^19.0.5 || 19.0.5-rc.6 || 19.0.5-rc.7 is clever: it allows existing RC users to pnpm install while still receiving the node renderer warning to upgrade.
  • isPrereleaseVersion and stripVersionPrefixAndBuild are cleanly extracted helpers with correct semver semantics.
  • Docs, llms-full.txt, generator, and test expectations are all updated consistently.
  • rsc_stable_package_version_target is correctly retired now that the pin is stable.
  • Generator failure messages no longer reference a hypothetical stable version — cleaner and less confusing.

Comment thread packages/react-on-rails-pro/package.json Outdated
Comment thread packages/react-on-rails-pro-node-renderer/src/shared/checkRscPeerCompatibility.ts Outdated
@justin808 justin808 force-pushed the codex/3965-rsc-pin-range branch from fbc5a10 to 0f5b833 Compare June 13, 2026 21:27
@claude

claude Bot commented Jun 13, 2026

Copy link
Copy Markdown
Contributor

Code Review — PR #3990: Pin Pro RSC runtime to stable 19.0.5

Overview

Clean, well-scoped promotion of react-on-rails-rsc from the coordinated RC prerelease (19.0.5-rc.7) to stable 19.0.5. The changes are internally consistent across all package.json files, the generator, the node renderer's runtime check, docs, and the llms-full generator. The PR is well-tested; I found no correctness bugs.

Positives

  • Consistent version update: all pin sites (root workspace, Pro dev dep, Pro dummy app, generator constant) move to stable in one shot — no drift.
  • Backward-compat peer spec: "^19.0.5 || 19.0.5-rc.6 || 19.0.5-rc.7" is much better than the previous wildcard "*". Explicit RC allowances let existing RC apps satisfy peer-dep checks while the runtime nudges them to upgrade.
  • Prerelease-at-stable warning logic: the isPrereleaseVersion / sameTuple guard is correct. 19.0.5-rc.6 and rc.7 now produce warn rather than a silent ok, which is the right migration nudge.
  • rsc_stable_package_version_target removal: the helper existed only to derive a stable target from a prerelease pin. Deleting it (and its test) is the right cleanup now that the pin is already stable.
  • llms-full split-mode refactor: generatedOutputs() cleanly handles both single-file and split modes, including stale-file cleanup in both generate and --check paths.

Issues / Suggestions

Medium — Warning message is misleading for the prerelease-at-stable case

warnMessage() at checkRscPeerCompatibility.ts:94-99 says:

react-on-rails-rsc 19.0.5-rc.6 is older than the recommended minimum 19.0.5

Semver technically agrees (prerelease < stable), but a user on 19.0.5-rc.6 seeing "is older than" will likely think they need to downgrade rather than promote to stable. A small branch in the warn message for the prerelease-same-tuple case would be clearer:

react-on-rails-rsc 19.0.5-rc.6 is a prerelease of the recommended minimum 19.0.5.
  Upgrade react-on-rails-rsc to the stable 19.0.5 release.

The test at checkRscPeerCompatibility.test.ts:39-43 only asserts .level === 'warn'; adding a .message assertion there would catch a regression if the message is later made prerelease-aware.

Low — ^19.0.5 peer range admits unvalidated future 19.x releases

The Pro peer dep "^19.0.5" resolves to >=19.0.5 <20.0.0, meaning a future react-on-rails-rsc@19.1.0 would satisfy peer checks and pass the runtime isAtLeast check without any runtime warning. This is an intentional forward-looking design (the PR description notes it, as does issue #3609), but the risk is that users pick up an untested 19.1.0+ before Pro validates it.

A comment on the peer entry noting this is intentionally open for coordinated advancement (like the existing comment on recommendedMin in rscPeerSupport.ts) would help the next engineer understand the intent rather than tighten it prematurely.

Nit — Ruby generator message says "while adding RspackPlugin"

rsc_dependency_pin_info and rsc_dependency_pin_failed_warning both say "the package keeps react-on-rails-rsc/WebpackPlugin compatible while adding react-on-rails-rsc/RspackPlugin." Now that the pin is stable the RspackPlugin is already there; "adding" implies it is new. Consider "while including react-on-rails-rsc/RspackPlugin" or just "and react-on-rails-rsc/RspackPlugin".

Nit — Only rc.6 is tested for the prerelease-at-stable warn path

The PR spec lists both 19.0.5-rc.6 and 19.0.5-rc.7 as allowed in the peer range. The test at line 39 covers rc.6. Since the behavior is identical for rc.7 the gap is not a bug, but adding a one-liner for rc.7 would document the intent explicitly.

Verdict

Approve with the warning-message wording as the one item worth addressing before merge. The misleading "is older than" message is the only thing a user would actually see and be confused by; everything else is a nit or a deliberate design choice already documented.

Comment thread packages/react-on-rails-pro-node-renderer/src/shared/checkRscPeerCompatibility.ts Outdated
Comment thread packages/react-on-rails-pro/package.json Outdated
@justin808

Copy link
Copy Markdown
Member Author

Addressed review feedback for current #3990 follow-up.

Triage:

  • MUST-FIX: packages/react-on-rails-pro/package.json peer range was wider than the documented 19.0.x RSC track. Fixed by changing stable peer allowance to ~19.0.5 while retaining 19.0.5-rc.6 and 19.0.5-rc.7.
  • MUST-FIX: checkRscPeerCompatibility.test.ts covered 19.0.5-rc.6 but not the deprecated 19.0.5-rc.7 pin. Added the rc.7 warning assertion.
  • OPTIONAL: documented the stable-floor prerelease warning heuristic in checkRscPeerCompatibility.ts.
  • OPTIONAL: added a generator-spec reminder to re-check message coherence if the RSC package pin returns to a prerelease in a future rollout.

Validation after fixes:

  • pnpm install --lockfile-only -> passed, no lockfile change
  • pnpm install --frozen-lockfile -> passed
  • pnpm --filter react-on-rails-pro-node-renderer exec jest tests/checkRscPeerCompatibility.test.ts tests/runRscPeerCompatibilityCheck.test.ts --runInBand -> passed
  • pnpm --filter react-on-rails-pro-node-renderer run build -> passed
  • (cd react_on_rails && BUNDLE_GEMFILE=../Gemfile bundle exec rubocop spec/react_on_rails/generators/js_dependency_manager_spec.rb && bundle exec rspec spec/react_on_rails/generators/js_dependency_manager_spec.rb) -> passed, 85 examples
  • pnpm start format.listDifferent -> passed
  • pnpm run lint -> passed
  • pnpm --filter react-on-rails-pro run type-check -> passed
  • pnpm --filter react-on-rails-pro run test:rsc -> passed, 5 suites / 17 tests
  • PATH="/tmp/lychee-v0.23.0:$PATH" bin/check-links -> passed, 2810 total / 0 errors

Resolved the four Claude review threads after pushing b1b5a704b0d4367cfaac426fe448cfab68079125.

Comment thread script/generate-llms-full.mjs Outdated
Comment thread packages/react-on-rails-pro-node-renderer/src/shared/checkRscPeerCompatibility.ts Outdated
@claude

claude Bot commented Jun 13, 2026

Copy link
Copy Markdown
Contributor

Code Review: Pin Pro RSC runtime to stable 19.0.5

Overall: Solid, well-scoped change. The RC → stable promotion is clean, the peer metadata is correct, and the split-output generator refactor is a nice improvement. Three issues worth addressing before merge.


Must-fix / correctness

1. warnMessage phrasing is misleading for the prerelease case (inline on checkRscPeerCompatibility.ts lines 154–161)

When a user has 19.0.5-rc.7 and the recommended minimum is 19.0.5, the message reads:

react-on-rails-rsc 19.0.5-rc.7 is older than the recommended minimum 19.0.5.

Semver-accurate, but a developer reading those patch numbers side by side will be confused. A simple fix: use "does not meet" instead of "is older than" — it's accurate for both the truly-old case and the prerelease-at-floor case without requiring extra branching.

2. Redundant (dead) validateSplitThreshold call in single-file mode (inline on generate-llms-full.mjs lines 435–439)

validateSplitThreshold only fails when outputSizeKib > SPLIT_THRESHOLD_KIB. The call at line 435 lives inside if (combinedSizeKib <= SPLIT_THRESHOLD_KIB), so the failure branch is unreachable — the guard and the validator check the same value in opposite directions. The call should be removed.


Should-fix / test coverage

3. No test for a prerelease above the stable floor returning ok (inline on checkRscPeerCompatibility.test.ts)

The code comment at lines 157–158 explicitly notes: "Higher prerelease tuples are outside this upgrade nudge." That invariant — e.g. 19.0.6-rc.1 returning ok — is untested. One extra case would guard against a future refactor accidentally widening the warn condition.


Minor / informational

  • Peer range ~19.0.5 || 19.0.5-rc.6 || 19.0.5-rc.7 is correct. npm excludes prereleases from tilde-range matching unless explicitly listed, so the explicit RC pins are necessary and properly scoped.
  • rsc_stable_package_version_target removal is clean — the helper only existed to derive a stable string from an RC pin; now that the pin is already stable it has no purpose.
  • finishGeneratedOutput with .trimEnd() is a good consistency improvement.
  • Stale-file cleanup (deleting OSS/Pro files when reverting to single mode) is correctly implemented on both the write path and the --check path.

@claude

claude Bot commented Jun 13, 2026

Copy link
Copy Markdown
Contributor

Code Review — PR #3990: Pin Pro RSC runtime to stable 19.0.5

Overview

Clean, well-scoped PR that promotes the RSC runtime from 19.0.5-rc.7 to stable 19.0.5. The three-part approach is sound: generator pin → peer dependency range → node-renderer recommended floor, all moving in concert. The llms-full split feature is a necessary housekeeping change to keep generated docs below the 2048 KiB ceiling.

What works well

  • The explicit peer range ~19.0.5 || 19.0.5-rc.6 || 19.0.5-rc.7 is exactly right: allows existing RC apps to install without breakage, while the node renderer warns them to upgrade to stable. The distinction between ~ (stable patch track) and explicit RC union entries (backward compat only) is well-reasoned.
  • Refactoring stripVersionPrefixAndBuild into a shared helper and adding isPrereleaseVersion keeps the version-parsing logic easy to follow.
  • The split-mode stale-file detection (both for check and write paths) handles the single→split and split→single transitions correctly, including orphaned file cleanup.
  • Test coverage is updated throughout and the new bash fixture test for split output is a good addition.

Issues

1. warnMessage is misleading for the prerelease-at-floor case (minor UX)

When rscVersion is 19.0.5-rc.7 and recommendedMin is 19.0.5, the returned message reads:

react-on-rails-rsc 19.0.5-rc.7 is older than the recommended minimum 19.0.5.

Developers who see the same 19.0.5 tuple but with an -rc.7 suffix will often read this as a false positive ("I thought 19.0.5-rc.7 was basically 19.0.5"). Semver ordering is correct, but a clearer message for the prerelease-at-floor path would help. See inline comment.

2. Dead validateSplitThreshold call in single-mode path (logic bug, non-crashing)

Inside generatedOutputs(), when combinedSizeKib <= SPLIT_THRESHOLD_KIB is true, the code immediately calls validateSplitThreshold(), which re-derives the same KiB value and checks > SPLIT_THRESHOLD_KIB. That condition can never be true — we're inside the <= branch. The fail() inside it is unreachable. See inline comment.

3. Missing test: prerelease above the stable floor should be ok (test gap)

The comment on the new prerelease check says "Higher prerelease tuples are outside this upgrade nudge", but no test verifies that 19.0.6-rc.1 (a prerelease of a higher patch) returns ok rather than warn\. The fix is one extra assertion. See inline comment.

4. docScope silently absorbs unknown doc categories (minor robustness)

Everything that doesn't start with pro/ is classified as oss. If a third top-level docs category is added later it will silently end up in the OSS split file rather than a distinct one. See inline comment.

Comment thread packages/react-on-rails-pro-node-renderer/src/shared/checkRscPeerCompatibility.ts Outdated
Comment thread script/generate-llms-full.mjs Outdated
@claude

claude Bot commented Jun 13, 2026

Copy link
Copy Markdown
Contributor

Code Review: Pin Pro RSC runtime to stable 19.0.5

Overview

This PR promotes react-on-rails-rsc from the coordinated prerelease (19.0.5-rc.7) to the stable 19.0.5 release across all install surfaces: the generator pin, workspace dev dependencies, Pro package peer metadata, and the Pro dummy app. It also adds a doc-split mechanism to handle llms-full.txt exceeding the 2048 KiB threshold.


Strengths

Peer compatibility logic (checkRscPeerCompatibility.ts)
The version check now enforces major and minor match (not just major), which is a meaningful tightening. The explicit allowedPrereleases list is a clean way to grandfather in users still on rc.6/rc.7 without silently accepting arbitrary prereleases. The three-tier outcome (ok / warn / error) maps well to the upgrade story.

Generator simplification
Removing rsc_stable_package_version_target and the rsc_ helper messages that explained a temporary prerelease situation is the right call now that the pin is stable. The spec is updated consistently, and the new test asserts what the message should not contain (latest, prerelease framing), which is more durable than testing exact text.

Doc split (generate-llms-full.mjs)
The split/single mode is transparent: llms-full.txt becomes a machine-readable index when the combined size crosses the threshold, and the check mode correctly validates staleness of all generated files plus the absence of stale split files when the script runs in single mode.

Test coverage
The new test cases cover the important decision boundaries: unlisted prerelease above stable → error, wrong minor line (19.1.0) → error, allowed RC versions → warn, stable at or above floor → ok.


Minor concerns

Non-obvious two-step path for allowed prereleases
rc.6 and rc.7 pass the isAllowedPrerelease guard (not blocked as error) and then reach the isPrereleaseAtRecommendedMin check where they get a warn because their numeric tuple [19,0,5] equals recommendedMinTuple. The intent — allowed RCs are not hard-blocked but still nudge users to upgrade — is correct, but the two-step flow is non-obvious. See inline comment.

allowedPrereleases entries must be stored without a v prefix
The comparison is allowedVersion === normalizedRscVersion where normalizedRscVersion has its v/= prefix stripped. The hardcoded values don't have a prefix, so it works today. But if a future editor adds 'v19.0.5-rc.8' to the list, the comparison silently fails and the version gets an error instead of the intended warn. See inline comment.

validateSplitThreshold called on the index file with the full 2048 KiB threshold
The split index (llms-full.txt) is tiny by design, so the threshold check will never fire. The call is harmless but slightly misleading. Low priority.


No security or correctness bugs found

The version parsing is defensive (malformed inputs coerce to 0 tuple segments), the prerelease stripping is consistent, and the doc generation writes to deterministic paths with proper check/write/delete logic.


Approve once minor concerns are addressed or acknowledged. The core logic is correct and well-tested. The inline comments below flag the two points worth a quick look before merge.

Comment thread packages/react-on-rails-pro-node-renderer/src/shared/checkRscPeerCompatibility.ts Outdated
Comment thread packages/react-on-rails-pro-node-renderer/src/shared/checkRscPeerCompatibility.ts Outdated
@justin808 justin808 force-pushed the codex/3965-rsc-pin-range branch from 5f511de to 1358d45 Compare June 14, 2026 01:19
@justin808 justin808 force-pushed the codex/3965-rsc-pin-range branch from 5805fa8 to 9ba40ab Compare June 14, 2026 21:08

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9ba40abdf4

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread packages/react-on-rails-pro/package.json Outdated
@claude

claude Bot commented Jun 14, 2026

Copy link
Copy Markdown
Contributor

Code Review — PR #3990: Pin Pro RSC runtime to stable 19.0.5

Overall: well-designed and ready with one small defensive fix recommended below.

The coordination between three sources of truth — the Ruby generator's RSC_PACKAGE_VERSION_PIN, the node-renderer's RSC_PEER_SUPPORT.recommendedMin, and the npm peer range in react-on-rails-pro/package.json — is properly enforced by the cross-file Jest invariants added in this PR. That pattern is excellent; it will prevent drift as future RCs arrive.

The prerelease gating logic is correct end-to-end:

  • Unlisted prereleases at the current minor (e.g., 19.0.5-rc.1) correctly surface as errors.
  • Listed RCs (rc.6, rc.7) pass the isAllowedRscPrerelease gate and then hit isPrereleaseAtRecommendedMin, yielding a warning — the right nudge without blocking boot.
  • Stable 19.0.5 and any higher 19.0.x patches return ok.
  • Prereleases on other supported minors (e.g., 19.2.0-rc.1) pass because rscTuple[1] !== recommendedMinMinor, which is intentional and tested.

One normalization asymmetry worth fixing (see inline), everything else is good.

Specific callouts:

  • stripVersionPrefixAndBuild correctly handles build-metadata (+...) and leading v/= prefixes on input versions — but this normalization isn't symmetrically applied to allowedPrereleases entries in the comparison (see inline on line 144).
  • The ordered-equality assertion in 'keeps allowed prereleases aligned with the Pro package peer exceptions' is slightly brittle to insertion order changes, but the PR notes this as a known nit and it's an acceptable trade-off for a currently stable, short list.
  • Documentation changes correctly retire all RC-version examples in favor of stable 19.0.5 across all three docs files.

Comment thread packages/react-on-rails-pro-node-renderer/src/shared/checkRscPeerCompatibility.ts Outdated

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: cbd0eb5ca6

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread packages/react-on-rails-pro/package.json

return false;
};

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

The last branch silently allows unlisted prereleases of any minor that isn't the recommendedMin minor (e.g., 19.2.0-rc.1 is allowed because rscTuple[1] === 2 !== 0 === recommendedMinMinor). This is intentional — isSupportedRscMinor already gates unsupported minors, and unlisted prereleases of a supported other minor (like the 19.2 line) are meant to pass through — but the design intent isn't obvious from the code alone. A short comment here would prevent future maintainers from removing this line thinking it's dead code when a new minor is added to supportedRanges:

Suggested change
const recommendedMinMinor = parseTuple(recommendedMin)[1];
// Unlisted prereleases of other supported minors (e.g. 19.2.0-rc.1 while recommendedMin is 19.0.5)
// pass through here; isSupportedRscMinor already rejected unsupported minors above.
return rscTuple[1] !== recommendedMinMinor;

);

expect(expectedStableRanges.every((stableRange) => peerRange.includes(stableRange))).toBe(true);
expect(peerPrereleases).toEqual([...RSC_PEER_SUPPORT.reactOnRailsRsc.allowedPrereleases]);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

The toEqual assertion checks both content and insertion order. Since peerPrereleases is extracted left-to-right from the peer range string in package.json, the order of ||-separated prerelease entries there must stay in sync with the order of allowedPrereleases in rscPeerSupport.ts. This coupling is correct but non-obvious — a short comment noting it would prevent a silent reorder from breaking the invariant unexpectedly.

@claude

claude Bot commented Jun 14, 2026

Copy link
Copy Markdown
Contributor

Code Review — PR #3990: Pin Pro RSC runtime to stable 19.0.5

Overall this is a clean, well-scoped PR. The logic is correct and the cross-package invariant tests are an excellent pattern. Two minor clarity notes:

1. isAllowedRscPrerelease: undocumented passthrough for other-minor prereleases

checkRscPeerCompatibility.ts line 153 (see inline comment) — the final return rscTuple[1] !== recommendedMinMinor silently passes unlisted prereleases of supported minors other than the recommendedMin minor (e.g., 19.2.0-rc.1 passes when recommendedMin is 19.0.5). This is intentional and correct — isSupportedRscMinor already rejects truly unsupported minors above, and unlisted 19.2.x prereleases should pass through to the React version check. But without a comment, the next person to add a new entry to supportedRanges may not realize this branch is load-bearing.

2. Invariant test: toEqual enforces prerelease ordering across packages

Test line 74 (see inline comment) — the peerPrereleases regex collects prereleases in the order they appear in the peer range string, and toEqual enforces that this matches allowedPrereleases in the same order. This is correct and a useful constraint, but the ordering dependency between package.json and rscPeerSupport.ts isn't documented at the assertion site. A brief note here would clarify why a reorder of one side would break the test.

No blocking issues

  • Version arithmetic and prerelease detection are correct.
  • Generator pin ↔ recommendedMin invariant test will catch any future desync.
  • Peer range ~19.0.5 || ~19.2.0 || 19.0.5-rc.6 || 19.0.5-rc.7 correctly covers the two supported RSC lines plus the upgrade-path RCs.
  • Both warn tiers (below-min stable and prerelease-at-min) produce the right messages.
  • Docs, lockfiles, and generated LLM text are consistently updated.

@github-actions

Copy link
Copy Markdown
Contributor

Pro Node Renderer Benchmark Summary

Benchmark RPS p50(ms) p90(ms) Status
Pro Node Renderer: simple_eval (non-RSC) 1244.58 ▼39.4% (2053.66) 4.65 ▲8.6% (4.28) 18.24 ▲145.5% (7.43) 200=37362
Pro Node Renderer: react_ssr (non-RSC) 1304.19 ▼28.2% (1816.31) 5.5 ▲10.8% (4.97) 13.77 ▲82.0% (7.57) 200=39129

▲/▼ non-zero change vs baseline · 0.0% exact/near-zero match · 🔴 significant regression · 🟢 significant improvement (tracked measures) · (n) = baseline

@justin808

Copy link
Copy Markdown
Member Author

Superseded by the current release-tracker direction.

I rechecked #3823 after #4026 merged. The tracker now says the final path targets the React/RSC 19.2 line and that #3988/#3990 are 19.0.5-era stable-pin variants to treat as superseded/obsolete unless a maintainer explicitly revives the 19.0.5 path.

Current head: 0c90b7d9147cda115d5da934f6b294c93b6facf2
Current status before close: checks still pending; two current-head Claude clarity comments open; PR body confidence block stale for the current head and stale against the tracker decision.

Merge recommendation: do not merge this PR. Close as superseded and route final-release RSC package work through the 19.2 line after react-on-rails-rsc@19.2.0-rc.1 is published and a follow-up React on Rails pin/update PR exists.

@justin808 justin808 closed this Jun 14, 2026
@claude

claude Bot commented Jun 14, 2026

Copy link
Copy Markdown
Contributor

Code Review — Pin Pro RSC runtime to stable 19.0.5

Overall: clean and well-reasoned. The stable pin promotion is straightforward, the prerelease gating logic (warn for explicitly listed RCs, error for anything else) is sound, and the cross-package invariant tests that guard generator pin ↔ RSC_PEER_SUPPORTpackage.json peer alignment are a genuinely useful safety net.

Findings

Minor — isAllowedRscPrerelease has a redundant double-return (checkRscPeerCompatibility.ts lines 140–151):
The if (condition) { return true; } return false; pattern is equivalent to return condition;. Inline comment added.

Minor — supportedRscRange message readability (lines 111–120):
With two supported minors the error string reads:

19.0.x stable >= 19.0.5, or 19.0.5-rc.6 / 19.0.5-rc.7 while upgrading from the RC line or 19.2.x

The double-or (one from the inline prerelease suffix, one from .join(' or ')) is technically unambiguous but reads awkwardly. The tests assert .toContain on substrings so they pass regardless — worth a look when the message wording is next revisited.

Nit — unsafe type assertion in test helper (checkRscPeerCompatibility.test.ts lines 26–27):
stableTuple casts .map(Number) to [number, number, number] via as, which TypeScript accepts without checking array length. Not a real risk with current recommendedMin format, but explicit indexing ([parts[0] ?? 0, parts[1] ?? 0, parts[2] ?? 0]) would be safer. Inline comment added.

Non-issue confirmed — ~19.0.5 peer range vs runtime check alignment:
The peer (~19.0.5 = >=19.0.5 <19.1.0) is intentionally narrower than the React range (~19.0.4). Stable 19.0.6+ clears isAtLeast cleanly; peer and runtime are in sync.

Non-issue confirmed — allowedPrereleases empty-array edge in test:
The "keeps allowed prereleases aligned" test uses Array.every which vacuously returns true on an empty array — intentional and noted in the adjacent comment (// Empty is valid when no prerelease exceptions are needed.).

Overall merge confidence is high. The three findings above are non-blocking style/robustness nits.

Comment on lines +136 to +152
const isAllowedRscPrerelease = (
rscVersion: string,
{ allowedPrereleases }: RscPeerSupport['reactOnRailsRsc'],
): boolean => {
if (!isPrereleaseVersion(rscVersion)) return true;

const normalizedRscVersion = stripVersionPrefixAndBuild(rscVersion).toLowerCase();
if (
allowedPrereleases.some(
(allowedVersion) => stripVersionPrefixAndBuild(allowedVersion).toLowerCase() === normalizedRscVersion,
)
) {
return true;
}

return false;
};

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

The if (condition) { return true; } ... return false; pattern here is equivalent to return condition;, which is cleaner:

Suggested change
const isAllowedRscPrerelease = (
rscVersion: string,
{ allowedPrereleases }: RscPeerSupport['reactOnRailsRsc'],
): boolean => {
if (!isPrereleaseVersion(rscVersion)) return true;
const normalizedRscVersion = stripVersionPrefixAndBuild(rscVersion).toLowerCase();
if (
allowedPrereleases.some(
(allowedVersion) => stripVersionPrefixAndBuild(allowedVersion).toLowerCase() === normalizedRscVersion,
)
) {
return true;
}
return false;
};
const isAllowedRscPrerelease = (
rscVersion: string,
{ allowedPrereleases }: RscPeerSupport['reactOnRailsRsc'],
): boolean => {
if (!isPrereleaseVersion(rscVersion)) return true;
const normalizedRscVersion = stripVersionPrefixAndBuild(rscVersion).toLowerCase();
return allowedPrereleases.some(
(allowedVersion) => stripVersionPrefixAndBuild(allowedVersion).toLowerCase() === normalizedRscVersion,
);
};

Comment on lines +26 to +27
const stableTuple = (version: string) =>
stableBase(version).split('.').map(Number) as [number, number, number];

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

The as [number, number, number] cast tells TypeScript the array is always length 3 without actually enforcing it — if recommendedMin were ever malformed (e.g. only two segments) the downstream destructuring in versionBelowRecommendedMin would silently receive undefined for patch. Explicit indexing avoids the unsound assertion:

Suggested change
const stableTuple = (version: string) =>
stableBase(version).split('.').map(Number) as [number, number, number];
const stableTuple = (version: string): [number, number, number] => {
const parts = stableBase(version).split('.').map(Number);
return [parts[0] ?? 0, parts[1] ?? 0, parts[2] ?? 0];
};

Comment on lines +111 to +120
return supportedMinors
.map((minor) => {
if (minor !== recommendedMinMinor) return `${supportedMajor}.${minor}.x`;

const stableRange = `${supportedMajor}.${minor}.x stable >= ${recommendedMin}`;
if (allowedPrereleases.length === 0) return stableRange;

return `${stableRange}, or ${allowedPrereleases.join(' / ')} while upgrading from the RC line`;
})
.join(' or ');

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

With the current two-minor configuration (0 and 2) the function produces:

19.0.x stable >= 19.0.5, or 19.0.5-rc.6 / 19.0.5-rc.7 while upgrading from the RC line or 19.2.x

The , or … while upgrading from the RC line suffix on the first item, followed immediately by a plain or 19.2.x from .join(' or '), reads slightly ambiguously — a user could parse 19.2.x as part of the RC upgrade path. The tests use .toContain on substrings so this won't cause test failures. Low priority, but worth a small tweak if the message is ever revisited (e.g. wrapping the prerelease clause in parentheses, or promoting the supported stable ranges to a separate sentence).

@github-actions

Copy link
Copy Markdown
Contributor

Core Benchmark Summary

Benchmark RPS p50(ms) p90(ms) Status
/: Core 3.63 ▲0.1% (3.63) 2217.84 ▲6.1% (2090.56) 2839.72 ▲6.4% (2667.82) 200=118
/client_side_hello_world: Core 739.65 ▲8.6% (681.34) 8.29 ▼8.3% (9.04) 20.05 ▲5.6% (18.99) 200=22344
/client_side_rescript_hello_world: Core 525.05 ▼20.0% (656.07) 11.14 ▲18.5% (9.4) 16.7 ▼12.6% (19.1) 200=15862
/client_side_hello_world_shared_store: Core 720.11 ▲11.8% (643.92) 8.4 ▼14.7% (9.84) 20.66 ▲3.1% (20.04) 200=21753
/client_side_hello_world_shared_store_controller: Core 743.24 ▲18.8% (625.7) 8.68 ▼14.4% (10.14) 17.61 ▼14.4% (20.57) 200=22454
/client_side_hello_world_shared_store_defer: Core 505.5 ▼21.0% (640.04) 11.6 ▲20.0% (9.66) 15.49 ▼21.3% (19.69) 200=15273
/server_side_hello_world_shared_store: Core 13.26 ▼14.5% (15.5) 445.29 ▼10.9% (499.82) 534.14 ▼18.9% (658.66) 200=409
/server_side_hello_world_shared_store_controller: Core 12.94 ▼15.8% (15.37) 461.68 ▼4.6% (483.77) 611.98 ▼5.9% (650.63) 200=398
/server_side_hello_world_shared_store_defer: Core 15.59 ▲0.1% (15.57) 366.62 ▼23.7% (480.67) 620.45 ▼5.0% (653.31) 200=480
/server_side_hello_world: Core 32.11 ▲2.9% (31.2) 258.04 ▲4.6% (246.66) 299.2 ▼0.7% (301.4) 200=978
/server_side_hello_world_hooks: Core 32.0 ▲2.6% (31.18) 263.97 ▲7.4% (245.77) 299.54 ▼2.7% (307.97) 200=974
/server_side_hello_world_props: Core 31.92 ▲2.1% (31.25) 261.34 ▲5.8% (247.13) 303.34 ▼2.3% (310.57) 200=973
/client_side_log_throw: Core 774.41 ▲15.0% (673.29) 8.24 ▼13.6% (9.54) 20.06 ▲7.2% (18.72) 200=23395
/server_side_log_throw: Core 30.89 ▲0.7% (30.68) 270.81 ▲6.3% (254.86) 316.08 ▲2.5% (308.3) 200=938
/server_side_log_throw_plain_js: Core 25.89 ▼16.2% (30.89) 171.21 ▼29.9% (244.1) 254.9 ▼16.9% (306.9) 200=792
/server_side_log_throw_raise: Core 26.86 ▼12.4% (30.66) 220.03 ▼9.1% (242.02) 239.88 ▼21.6% (305.83) 3xx=821
/server_side_log_throw_raise_invoker: Core 851.41 ▲7.7% (790.47) 7.85 ▼6.6% (8.4) 16.64 ▲3.3% (16.11) 200=25721
/server_side_hello_world_es5: Core 25.87 ▼15.4% (30.57) 232.74 ▼3.3% (240.73) 354.75 ▲17.0% (303.31) 200=786
/server_side_redux_app: Core 30.87 ▲2.7% (30.06) 271.1 ▲7.0% (253.41) 314.31 ▲0.6% (312.35) 200=939
/server_side_hello_world_with_options: Core 25.92 ▼16.6% (31.08) 222.9 ▼9.4% (245.94) 297.14 ▼2.3% (304.25) 200=794
/server_side_redux_app_cached: Core 775.35 ▲16.9% (663.34) 11.26 ▲12.5% (10.01) 16.62 ▼8.6% (18.18) 200=23422
/client_side_manual_render: Core 769.29 ▲15.4% (666.85) 8.7 ▼9.8% (9.65) 17.07 ▼11.0% (19.17) 200=23241
/render_js: Core 33.87 ▲0.8% (33.62) 95.12 🟢 59.7% (236.09) 273.65 ▼4.1% (285.29) 200=1037
/react_router: Core 29.98 ▲3.0% (29.12) 279.68 ▲6.4% (262.93) 323.16 ▼1.4% (327.81) 200=913
/pure_component: Core 26.16 ▼18.6% (32.12) 223.2 ▼11.0% (250.78) 308.02 ▲1.9% (302.36) 200=797
/react_compiler_example: Core 31.65 ▼2.9% (32.6) 270.34 ▲12.2% (240.88) 308.45 ▲2.7% (300.21) 200=962
/css_modules_images_fonts_example: Core 31.29 ▲1.2% (30.91) 271.36 ▲7.7% (252.02) 313.94 ▲2.5% (306.15) 200=950
/turbolinks_cache_disabled: Core 664.72 ▼2.3% (680.09) 9.29 ▼0.5% (9.34) 20.42 ▲7.6% (18.98) 200=20084
/rendered_html: Core 31.55 ▲0.9% (31.26) 269.14 ▲9.0% (246.88) 308.22 ▲0.7% (306.11) 200=959
/xhr_refresh: Core 13.22 ▼16.3% (15.79) 452.1 ▼2.2% (462.17) 588.41 ▼4.8% (618.38) 200=406
/react_helmet: Core 30.79 ▼0.1% (30.81) 274.47 ▲11.8% (245.4) 311.79 ▲1.5% (307.19) 200=939
/broken_app: Core 30.6 ▼0.2% (30.66) 276.11 ▲9.4% (252.28) 317.28 ▲2.7% (308.96) 200=931
/image_example: Core 31.23 ▲0.5% (31.08) 196.08 ▼22.1% (251.67) 295.43 ▼4.1% (308.01) 200=956
/font_optimization_example: Core 823.1 ▲8.7% (757.11) 7.92 ▼7.2% (8.53) 17.37 ▲3.9% (16.72) 200=24864
/turbo_frame_tag_hello_world: Core 563.15 ▼22.0% (721.87) 10.33 ▲24.0% (8.33) 14.13 ▼19.9% (17.63) 200=17015
/manual_render_test: Core 778.88 ▲17.9% (660.76) 8.42 ▼8.7% (9.22) 17.13 ▼6.1% (18.24) 200=23532

▲/▼ non-zero change vs baseline · 0.0% exact/near-zero match · 🔴 significant regression · 🟢 significant improvement (tracked measures) · (n) = baseline

@github-actions

Copy link
Copy Markdown
Contributor

Pro (shard 2/2) Benchmark Summary

Benchmark RPS p50(ms) p90(ms) Status
/empty: Pro 1234.61 ▼0.4% (1239.0) 6.39 ▲10.8% (5.77) 9.91 ▲3.1% (9.61) 200=37291
/ssr_shell_error: Pro 355.27 ▲3.2% (344.28) 17.88 ▼12.6% (20.46) 29.98 ▼12.7% (34.36) 200=10739
/ssr_sync_error: Pro 357.35 ▲5.0% (340.39) 21.25 ▼0.2% (21.3) 32.96 ▼7.6% (35.65) 200=10799
/rsc_component_error: Pro 294.99 ▼13.6% (341.43) 19.32 ▼6.7% (20.71) 61.49 ▲68.1% (36.59) 200=8914
/non_existing_stream_react_component: Pro 326.56 ▼9.1% (359.35) 14.48 ▼28.6% (20.29) 20.68 ▼38.6% (33.7) 200=9935
/server_side_redux_app_cached: Pro 413.18 ▲9.3% (378.11) 19.05 ▲1.4% (18.78) 29.28 ▼7.4% (31.61) 200=12492
/loadable: Pro 295.7 ▼7.1% (318.13) 18.62 ▼17.1% (22.47) 35.91 ▲2.8% (34.94) 200=8939
/apollo_graphql: Pro 101.94 ▼28.0% (141.57) 55.31 ▲8.6% (50.93) 104.31 ▲27.6% (81.72) 200=3382,3xx=4
/console_logs_in_async_server: Pro 3.15 ▲0.7% (3.13) 2123.8 ▲0.1% (2121.8) 2141.1 ▼1.1% (2165.69) 200=108
/stream_error_demo: Pro 323.54 ▼5.1% (340.98) 23.44 ▲17.4% (19.97) 35.82 ▲8.3% (33.07) 200=9779
/stream_async_components: Pro 323.24 ▼4.8% (339.39) 23.65 ▲9.1% (21.68) 39.1 ▲9.5% (35.69) 200=9770
/rsc_posts_page_over_http: Pro 265.95 ▼20.6% (335.1) 21.38 ▲2.2% (20.93) 26.47 ▼24.7% (35.16) 200=8090
/rsc_echo_props: Pro 230.97 ▲1.1% (228.51) 34.87 ▲11.2% (31.36) 51.53 ▲4.4% (49.34) 200=6982
/async_on_server_sync_on_client_client_render: Pro 354.67 ▲0.3% (353.6) 21.98 ▲8.5% (20.25) 34.78 ▲1.0% (34.43) 200=10650
/server_router_client_render: Pro 331.42 ▼8.7% (362.8) 22.98 ▲15.3% (19.94) 34.42 ▲10.9% (31.05) 200=10016
/unwrapped_rsc_route_stream_render: Pro 331.09 ▼5.7% (351.09) 21.87 ▲11.5% (19.61) 36.49 ▲4.7% (34.84) 200=10007
/async_render_function_returns_component: Pro 359.33 ▲1.8% (353.05) 21.35 ▲0.7% (21.21) 32.77 ▼2.7% (33.67) 200=10860
/native_metadata: Pro 288.96 ▼16.2% (344.95) 20.06 ▼1.7% (20.41) 74.88 ▲97.2% (37.98) 200=8732
/hybrid_metadata_streaming: Pro 303.49 ▼10.9% (340.57) 15.62 ▼26.3% (21.19) 22.39 ▼37.7% (35.96) 200=9233
/cache_demo: Pro 355.2 ▲5.2% (337.79) 9.51 ▼55.8% (21.49) 28.24 ▼22.8% (36.58) 200=10807
/client_side_hello_world: Pro 399.19 ▲5.6% (378.13) 19.17 ▼1.2% (19.39) 28.47 ▼8.6% (31.15) 200=12063
/client_side_hello_world_shared_store_controller: Pro 379.12 ▲9.7% (345.57) 16.58 ▼18.6% (20.37) 27.7 ▼12.6% (31.71) 200=11459
/server_side_hello_world_shared_store: Pro 253.47 ▼12.0% (288.19) 22.47 ▼9.5% (24.83) 53.01 ▲37.2% (38.64) 200=7660
/server_side_hello_world_shared_store_defer: Pro 313.54 ▲7.2% (292.35) 25.64 ▲0.9% (25.42) 38.88 0.0% (38.9) 200=9474
/server_side_hello_world_hooks: Pro 358.89 ▲0.8% (355.91) 21.21 ▲2.8% (20.64) 33.17 ▼0.8% (33.43) 200=10847
/server_side_log_throw: Pro 343.07 ▼2.2% (350.88) 23.01 ▲9.2% (21.07) 34.71 ▲5.1% (33.01) 200=10364
/server_side_log_throw_raise: Pro 703.43 ▲4.6% (672.46) 11.14 ▲6.5% (10.46) 19.27 ▲10.2% (17.49) 3xx=21250
/server_side_hello_world_es5: Pro 302.34 ▼11.6% (342.12) 18.77 ▼13.7% (21.74) 22.16 ▼35.7% (34.47) 200=9198
/server_side_hello_world_with_options: Pro 365.54 ▲8.5% (336.82) 17.17 ▼21.0% (21.73) 28.67 ▼17.9% (34.9) 200=11050
/client_side_manual_render: Pro 403.03 ▲7.5% (374.83) 18.93 ▼2.1% (19.34) 30.16 ▼2.7% (30.99) 200=12183
/react_router: Pro 448.26 ▲11.5% (401.93) 14.25 ▼18.1% (17.4) 23.78 ▼19.0% (29.35) 200=13550
/css_modules_images_fonts_example: Pro 311.36 ▼8.4% (339.92) 18.44 ▼12.8% (21.14) 59.76 ▲58.9% (37.61) 200=9408
/rendered_html: Pro 394.01 ▲12.8% (349.35) 19.96 ▼5.1% (21.02) 31.35 ▼9.4% (34.61) 200=11905
/react_helmet: Pro 382.4 ▲12.6% (339.7) 20.72 ▼4.8% (21.76) 32.11 ▼7.6% (34.76) 200=11555
/image_example: Pro 308.0 ▼10.6% (344.62) 18.54 ▼13.3% (21.39) 51.83 ▲49.0% (34.78) 200=9307
/posts_page: Pro 263.12 ▲10.4% (238.32) 23.41 ▼21.7% (29.92) 39.07 ▼15.0% (45.99) 200=7957

▲/▼ non-zero change vs baseline · 0.0% exact/near-zero match · 🔴 significant regression · 🟢 significant improvement (tracked measures) · (n) = baseline

@github-actions

Copy link
Copy Markdown
Contributor

Pro (shard 1/2) Benchmark Summary

Benchmark RPS p50(ms) p90(ms) Status
/: Pro 204.63 ▲10.7% (184.89) 27.25 ▼33.8% (41.17) 53.86 ▼12.0% (61.17) 200=6227
/error_scenarios_hub: Pro 416.03 ▲11.0% (374.81) 18.44 ▼1.2% (18.65) 29.45 ▼0.9% (29.72) 200=12490
/ssr_async_error: Pro 390.93 ▲12.6% (347.07) 19.89 ▼5.3% (21.0) 31.89 ▼8.2% (34.72) 200=11812
/ssr_async_prop_error: Pro 311.9 ▼7.6% (337.63) 18.04 ▼16.9% (21.7) 22.85 ▼35.5% (35.41) 200=9489
/non_existing_react_component: Pro 401.78 ▲10.9% (362.44) 19.69 ▼3.2% (20.34) 30.65 ▼6.1% (32.65) 200=12139
/non_existing_rsc_payload: Pro 350.03 ▼8.0% (380.44) 16.43 ▼15.6% (19.46) 48.81 ▲50.5% (32.44) 200=10577
/cached_react_helmet: Pro 435.39 ▲12.8% (386.06) 18.12 ▼0.6% (18.22) 28.23 ▼10.7% (31.62) 200=13154
/cached_redux_component: Pro 348.3 ▼12.4% (397.61) 16.38 ▼11.8% (18.56) 55.48 ▲83.5% (30.23) 200=10523
/lazy_apollo_graphql: Pro 138.35 ▼6.3% (147.61) 55.64 ▲13.2% (49.13) 82.54 ▲6.7% (77.34) 200=4183
/redis_receiver: Pro 89.27 ▲4.7% (85.24) 60.62 ▼6.2% (64.6) 161.98 ▲9.4% (148.13) 200=2700
/stream_shell_error_demo: Pro 323.29 ▼7.4% (349.12) 17.68 ▼11.8% (20.03) 74.65 ▲116.7% (34.46) 200=9769
/test_incremental_rendering: Pro 322.48 ▼7.3% (348.05) 17.54 ▼11.4% (19.79) 22.51 ▼29.0% (31.71) 200=9747
/rsc_posts_page_over_redis: Pro 96.48 ▼0.7% (97.14) 75.11 ▲4.0% (72.21) 111.92 ▼3.6% (116.09) 200=2920
/async_on_server_sync_on_client: Pro 367.4 ▲12.2% (327.35) 17.06 ▼21.0% (21.6) 28.69 ▼25.1% (38.29) 200=11107
/server_router: Pro 373.57 ▲8.1% (345.5) 14.79 ▼28.6% (20.72) 28.06 ▼18.6% (34.48) 200=11363
/unwrapped_rsc_route_client_render: Pro 430.7 ▲11.4% (386.53) 17.86 0.0% (17.86) 25.85 ▼12.0% (29.36) 200=13012
/async_render_function_returns_string: Pro 399.56 ▲13.7% (351.26) 19.61 ▼2.7% (20.16) 30.98 ▼8.5% (33.86) 200=12071
/async_components_demo: Pro 188.93 ▼12.1% (214.94) 30.58 ▼13.1% (35.18) 51.76 ▲2.3% (50.57) 200=5712
/stream_native_metadata: Pro 384.45 ▲9.9% (349.91) 19.71 ▼3.0% (20.32) 30.59 ▼14.1% (35.6) 200=11617
/rsc_native_metadata: Pro 316.91 ▼5.9% (336.82) 17.86 ▼15.1% (21.04) 21.85 ▼40.5% (36.69) 200=9639
/react_intl_rsc_demo: Pro 378.96 ▲11.4% (340.16) 22.88 ▲8.1% (21.16) 31.51 ▼13.2% (36.3) 200=11450
/client_side_hello_world_shared_store: Pro 391.16 ▲10.4% (354.45) 19.8 ▼2.8% (20.36) 30.7 ▼4.1% (32.03) 200=11816
/client_side_hello_world_shared_store_defer: Pro 385.26 ▲11.7% (345.0) 19.93 ▼2.0% (20.33) 31.71 ▼0.6% (31.89) 200=11641
/server_side_hello_world_shared_store_controller: Pro 333.15 ▲13.1% (294.47) 24.11 ▼3.6% (25.01) 36.48 ▼7.9% (39.63) 200=10067
/server_side_hello_world: Pro 385.05 ▲14.3% (336.82) 20.41 ▼3.3% (21.11) 31.81 ▼11.4% (35.9) 200=11634
/client_side_log_throw: Pro 428.16 ▲13.7% (376.61) 20.08 ▲10.1% (18.24) 26.85 ▼13.0% (30.85) 200=12935
/server_side_log_throw_plain_js: Pro 349.45 ▼10.3% (389.7) 16.03 ▼15.0% (18.86) 19.73 ▼36.6% (31.12) 200=10628
/server_side_log_throw_raise_invoker: Pro 394.31 ▼7.4% (425.6) 14.51 ▼11.5% (16.4) 20.8 ▼20.4% (26.12) 200=11916
/server_side_redux_app: Pro 387.11 ▲12.2% (344.9) 20.31 ▼5.8% (21.56) 29.67 ▼15.7% (35.18) 200=11708
/server_side_redux_app_cached: Pro 428.36 ▲13.3% (378.11) 18.21 ▼3.1% (18.78) 27.07 ▼14.4% (31.61) 200=12944
/render_js: Pro 437.29 ▲12.4% (389.21) 17.64 ▼3.5% (18.29) 26.13 ▼13.5% (30.22) 200=13212
/pure_component: Pro 400.51 ▲13.9% (351.67) 19.75 ▼5.2% (20.82) 30.8 ▼11.8% (34.93) 200=12101
/turbolinks_cache_disabled: Pro 425.31 ▲10.1% (386.42) 17.76 ▼6.1% (18.91) 26.72 ▼11.8% (30.28) 200=12851
/xhr_refresh: Pro 265.98 ▼8.9% (292.12) 21.3 ▼12.7% (24.41) 24.12 ▼37.6% (38.63) 200=8091
/broken_app: Pro 316.97 ▼9.5% (350.27) 18.02 ▼16.0% (21.45) 62.38 ▲85.6% (33.62) 200=9578
/server_render_with_timeout: Pro 395.06 ▲14.7% (344.5) 13.97 ▼32.9% (20.81) 26.72 ▼22.6% (34.51) 200=12017

▲/▼ non-zero change vs baseline · 0.0% exact/near-zero match · 🔴 significant regression · 🟢 significant improvement (tracked measures) · (n) = baseline

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant