fix(benchmarks): seed Pro dummy DB so /posts_page stops 500ing (#3602) by justin808 · Pull Request #3615 · shakacode/react_on_rails

justin808 · 2026-06-04T21:33:58Z

Summary

Fixes the Pro benchmark's /posts_page route, which reported a 100% failure rate (5xx on every request) while every other route was green (see #3602 and the #3586 benchmark comment).

Root cause

The benchmark workflow builds production assets and starts the server, but never creates, migrates, or seeds the production database. So db/production.sqlite3 has no posts table, and the route's first query raises:

ActiveRecord::StatementInvalid: SQLite3::SQLException: no such table: posts

/posts_page is the only synchronous (non-streaming) benchmark route that reads the database directly, so it's the only one where the failure surfaces as a 5xx. The streaming RSC posts routes (rsc_posts_page_over_http, rsc_posts_page_over_redis) hit the same broken DB but return HTTP 200 because the status line is flushed before the body errors — which is why they showed 0% fail.

Verified locally: with the tables present but empty the route returns 200 ("No posts found"); only a missing table produces the 500.

Changes

.github/workflows/benchmark.yml — add a Prepare and seed benchmark database step (RAILS_ENV=production bundle exec rails db:prepare) before the server starts, gated to the Pro Rails suite (server_kind == 'rails' && pro_env == 'true'). db:prepare creates the DB, loads the schema, and runs the seeds on first creation.
react_on_rails_pro/spec/dummy/db/seeds.rb — rewrite to be deterministic and free of the faker gem. faker lives in the :development, :test bundler groups and is not loaded under RAILS_ENV=production, so the old seeds raised NameError: uninitialized constant Faker when run by the benchmark. Deterministic data also keeps benchmark runs reproducible run-to-run.
react_on_rails_pro/spec/dummy/spec/requests/posts_page_spec.rb — new integration test (per the issue's request) that seeds records and asserts /posts_page server-renders the posts and returns 200, plus a case asserting 200 (not 500) with an empty table. The spec self-loads the schema because the suite intentionally leaves maintain_test_schema! disabled.

Side effect (one-time main re-baseline)

rsc_posts_page_over_redis fetches its data via the in-process Rails DB, so with a seeded DB it now renders real posts/comments/users instead of erroring out fast. Its timing will shift on the first main-push benchmark after merge (a one-time Bencher re-baseline). rsc_posts_page_over_http is unaffected — it fetches from a hard-coded http://localhost:3000, which is not the benchmark server (port 3001), so it never fetched real data regardless.

Testing

Reproduced the exact 500 (missing-table) and confirmed empty-table returns 200.
Confirmed RAILS_ENV=production rails db:prepare now seeds cleanly (10 users / 50 posts / 173 comments) and the posts_page controller assembles posts with nested comments + users.
New spec parses and runs; locally it exercises schema-load → seed → routing → controller and stops only at SSR (no local ssr-generated/server-bundle.js). The CI Pro rspec job builds the bundle and runs the node renderer, so SSR completes there.
bundle exec rubocop clean on the changed Ruby files; actionlint clean on the new workflow step.

Fixes #3602

🤖 Generated with Claude Code

Note

Low Risk
Benchmark CI and dummy-app seeds/tests only; no production app auth or payment paths.

Overview
Fixes Pro benchmark 100% 5xx on /posts_page by ensuring the production DB exists and is populated before the server starts, and by making seeds safe under RAILS_ENV=production.

CI (.github/workflows/benchmark.yml): For Pro Rails suites only, runs rails db:prepare after asset build and before the server, then aborts if posts, users, or comments counts are zero—so a missing table or skipped seed fails the job instead of looking like a healthy empty page.

Seeds (db/seeds.rb): Replaces Faker-based random data with deterministic lorem-style content so db:prepare works without the dev/test-only faker gem and benchmark payloads stay reproducible.

Tests: Adds db/seeds_spec.rb (loads seeds with Faker hidden; checks counts and determinism) and posts_page_spec.rb (SSR returns 200 with seeded posts; empty DB returns 200 with "No posts found", not 500).

^{Reviewed by Cursor Bugbot for commit 7e4519b. Bugbot is set up for automated code reviews on this repo. Configure here.}

Summary by CodeRabbit

Tests
- Added/updated integration tests for the Pro benchmark posts page (populated and empty scenarios).
- Added a seeds spec to verify deterministic, repeatable seeding and behavior when Faker is unavailable.
Chores
- CI now prepares and validates the benchmark database for Pro Rails suites before server startup.
- Replaced nondeterministic seed data with deterministic, CI-friendly seeding and clear success output.

Merge decision / follow-up

Minor benchmark cleanup nits are tracked in #3638 so this approved/green reliability fix can merge without restarting CI for readability-only changes.

coderabbitai · 2026-06-04T21:35:01Z

Walkthrough

Replaces nondeterministic dummy seeds with deterministic generators, adds RSpec tests for seeds determinism and the /posts_page route, and adds a conditional CI workflow step that prepares and verifies the Rails benchmark database for Pro Rails runs.

Changes

Deterministic Benchmark Data and Testing

Layer / File(s)	Summary
Deterministic seed data and generation helpers `react_on_rails_pro/spec/dummy/db/seeds.rb`	Deterministic seed configuration and lorem generator lambdas; clears `Comment`/`Post`/`User` and creates deterministic users, posts, and comments; updates output to include final record counts.
Seeds determinism and behavior specs `react_on_rails_pro/spec/dummy/spec/db/seeds_spec.rb`	New RSpec suite that loads schema on demand, silences seed output, verifies seeds run without `Faker`, and asserts repeated runs produce identical counts and ordered post titles.
Posts page integration tests `react_on_rails_pro/spec/dummy/spec/requests/posts_page_spec.rb`	Adds RSpec request specs that load schema on demand, clear and deterministically seed the DB in hooks, assert `GET /posts_page` returns HTTP 200 and contains sentinel post titles, and assert "No posts found" when DB is empty.
CI database preparation for Rails benchmark `.github/workflows/benchmark.yml`	Adds a conditional CI step for Pro Rails matrix jobs that sets `RAILS_ENV=production`/`NODE_ENV=production`, runs `bundle exec rails db:prepare`, and aborts the job if `Post`/`User`/`Comment` counts are zero before starting benchmark routes.

Sequence Diagram

sequenceDiagram
    participant GitHubCI as GitHub Actions
    participant BenchmarkJob as benchmark job
    participant RailsApp as Rails runner
    participant DB as Database
    participant RSpec as RSpec

    GitHubCI->>BenchmarkJob: trigger benchmark job (Pro Rails matrix)
    BenchmarkJob->>RailsApp: run db:prepare (RAILS_ENV=production NODE_ENV=production)
    RailsApp->>DB: migrate/create schema and run db/seeds.rb
    DB-->>RailsApp: return inserted Users/Posts/Comments
    BenchmarkJob->>RailsApp: verify Post/User/Comment counts (abort if any zero)
    BenchmarkJob->>RSpec: start test suite
    RSpec->>RailsApp: clear and deterministically seed DB (tests)
    RSpec->>RailsApp: GET /posts_page
    RailsApp->>DB: query posts and comments
    RailsApp-->>RSpec: HTTP 200 with rendered HTML (posts or "No posts found")

Estimated Code Review Effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related issues

Benchmark workflow follow-ups: unify suite jobs, split track_benchmarks, JSON-based regression detection #3459 — touches the benchmark workflow; this PR adds a Rails DB prepare/verify step relevant to that workflow work.

Possibly related PRs

shakacode/react_on_rails#3528: Related modifications to the benchmark workflow and Pro Rails suite orchestration.

Suggested reviewers

AbanoubGhadban

"I hop through rows with measured care,
planting words that always stick and share,
CI hums, rails wake, the seeds align,
posts and comments form a steady line,
a rabbit smiles — deterministic fare."

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: fixing a benchmark failure by seeding the Pro dummy database so the /posts_page route stops returning 500 errors.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
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 jg-conductor/3602-fix

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.}

greptile-apps · 2026-06-04T21:38:18Z

Greptile Summary

This PR fixes the /posts_page benchmark route's 100% 5xx failure rate by seeding the production SQLite database before the benchmark server starts, rewriting seeds.rb to be deterministic and free of the faker gem, and adding an integration spec that guards against the regression recurring.

Workflow — adds a db:prepare step gated to the Pro Rails matrix entry (server_kind == 'rails' && pro_env == 'true'), placed correctly before the server start.
seeds.rb — faker dependency removed; top-level constants like USER_COUNT will emit "already initialized constant" warnings if load-ed more than once.
posts_page_spec.rb — integration spec self-loads schema; the guard checks only :posts, which could miss absent :users or :comments tables.

Confidence Score: 4/5

Safe to merge; the fix is well-scoped and targets a clear root cause without touching production application logic.

The workflow condition, step ordering, and seeds logic are all correct. The two findings are robustness concerns that do not affect CI correctness for the benchmark fix.

seeds.rb (constant redefinition warnings) and posts_page_spec.rb (schema guard scope) warrant a quick look.

Important Files Changed

Filename	Overview
.github/workflows/benchmark.yml	Adds a db:prepare step gated to the Pro Rails suite; condition and placement are correct.
react_on_rails_pro/spec/dummy/db/seeds.rb	Rewrites seeds to be deterministic and faker-free; top-level constants will warn if load-ed more than once.
react_on_rails_pro/spec/dummy/spec/requests/posts_page_spec.rb	New integration spec; schema guard checks only :posts, missing :users/:comments would bypass the load.

_{Reviews (1): Last reviewed commit: "fix(benchmarks): seed Pro dummy DB so /p..." | Re-trigger Greptile}

coderabbitai

🧹 Nitpick comments (1)

react_on_rails_pro/spec/dummy/db/seeds.rb (1)

46-49: ⚡ Quick win

Break the long create! call across multiple lines.

The combined line exceeds the 120-character limit. As per coding guidelines, Ruby code should have a max line length of 120 characters.

♻️ Proposed refactor to improve readability

-    posts << user.posts.create!(
-      title: lorem_sentence.call(3, seed),
-      body: Array.new(3) { |p| lorem_paragraph.call(4, seed + p) }.join("\n\n")
-    )
+    posts << user.posts.create!(
+      title: lorem_sentence.call(3, seed),
+      body: Array.new(3) { |p| lorem_paragraph.call(4, seed + p) }
+             .join("\n\n")
+    )

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@react_on_rails_pro/spec/dummy/db/seeds.rb` around lines 46 - 49, The
single-line user.posts.create! call is over 120 chars; split the arguments onto
multiple lines to satisfy the line-length rule and improve readability: place
the opening parenthesis after create!, put title: lorem_sentence.call(3, seed)
on its own line, body: Array.new(3) { |p| lorem_paragraph.call(4, seed + p)
}.join("\n\n") on its own line, and close the parenthesis on a new line; keep
the surrounding posts << ... wrapper and preserve the use of create!, title,
body, lorem_sentence, and lorem_paragraph.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@react_on_rails_pro/spec/dummy/db/seeds.rb`:
- Around line 46-49: The single-line user.posts.create! call is over 120 chars;
split the arguments onto multiple lines to satisfy the line-length rule and
improve readability: place the opening parenthesis after create!, put title:
lorem_sentence.call(3, seed) on its own line, body: Array.new(3) { |p|
lorem_paragraph.call(4, seed + p) }.join("\n\n") on its own line, and close the
parenthesis on a new line; keep the surrounding posts << ... wrapper and
preserve the use of create!, title, body, lorem_sentence, and lorem_paragraph.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: f713fefe-fd04-4c04-b8a1-4dc0524f4704

📥 Commits

Reviewing files that changed from the base of the PR and between 511fc23 and 24b50e8.

📒 Files selected for processing (3)

.github/workflows/benchmark.yml
react_on_rails_pro/spec/dummy/db/seeds.rb
react_on_rails_pro/spec/dummy/spec/requests/posts_page_spec.rb

claude · 2026-06-04T22:04:03Z

Code Review - Summary

Clean, targeted fix for the benchmark 100% failure rate on /posts_page. Root cause diagnosis is accurate, changes are minimal and well-scoped. Three small items to consider before merge (see inline comments for specifics).

What is good:

Root cause analysis is precise -- the missing-table vs empty-table distinction (500 vs 200) is correctly identified.
The db:prepare step is correctly gated after the asset build; SECRET_KEY_BASE is already set at the job level so the step inherits it.
Deterministic seeding math is correct: 10 users x cycling 3-7 posts/user = 50 posts, cycling 2-5 comments/post = 173 total. Matches PR description.
The table_exists check guard in the spec is a clean workaround for intentionally disabled maintain_test_schema!.

Issues (see inline comments):

Top-level Ruby constants in seeds.rb (USER_COUNT, POSTS_PER_USER, COMMENTS_PER_POST, LOREM) will generate 'already initialized constant' warnings when db:seed is run more than once in the same process, since db:seed uses load not require. Use local variables instead.
ActiveRecord::Base.connection is deprecated in Rails 7.1+; the repo is on 7.2.3. Use Post.connection.table_exists? to avoid deprecation notices.
(Nit) The empty-table example re-runs delete_all manually inside the example body. A nested context block with its own before would be cleaner.

No concerns on:

Workflow if-expression syntax (matrix.pro_env == 'true') is consistent with all other guards in benchmark.yml.
Delete order (Comments then Posts then Users) is correct for the FK constraints.
POSTS_PER_USER.size / COMMENTS_PER_POST.size correctly yield element counts (5 and 4) and the modulo logic cycles through all values in each range.

The Pro benchmark suite reported `/posts_page` at a 100% failure rate (5xx on every request) while every other route was green. Root cause: the benchmark workflow never creates/migrates/seeds the production database, so the `posts` table does not exist and the route's first query raises ActiveRecord::StatementInvalid (no such table: posts). `/posts_page` is the only synchronous benchmark route that reads the database directly. The streaming RSC posts routes hit the same broken DB but return HTTP 200 because the status line is flushed before the body errors, so the failure only surfaced here. Changes: - benchmark.yml: add a "Prepare and seed benchmark database" step (RAILS_ENV=production `rails db:prepare`) before the server starts, gated to the Pro Rails suite. db:prepare creates the DB, loads the schema, and runs the seeds. - db/seeds.rb: rewrite to be deterministic and free of the faker gem. faker is a development/test-only dependency and is not loaded under RAILS_ENV=production, so the previous seeds raised NameError there. Deterministic data also keeps benchmark runs reproducible. - spec/requests/posts_page_spec.rb: new integration test that seeds records and asserts /posts_page server-renders the posts and returns 200 (and 200, not 500, with an empty table), guarding against a regression. The spec self-loads the schema since the suite leaves maintain_test_schema! disabled. Fixes #3602 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Address PR review findings on #3615: - benchmark.yml: db:prepare only seeds on first DB creation, so an already-present-but-empty DB would silently skip seeding and serve a 200 "No posts found" payload that the benchmark scores as healthy. Replace the unconditional success echo with a `rails runner` row-count check that fails the job loudly if zero posts were seeded, and correct the step comment to state the seed-on-creation semantics. - posts_page_spec.rb: the before block always loads the schema, so the spec never reproduces the missing-table 500 its header claimed to guard. Reword the header to accurately describe what it covers (the render + empty-data paths, with the missing-table 500 prevented upstream by seeding the benchmark DB). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

coderabbitai

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/benchmark.yml:
- Line 408: Replace direct expansion of ${{ matrix.suite_name }} in the echo
step by routing the matrix value through an environment variable: set an env key
(e.g., SUITE_NAME: ${{ matrix.suite_name }}) on the step and change the command
to echo "🌱 Preparing and seeding $SUITE_NAME benchmark database..." so the
workflow uses the env variable instead of inline template expansion (refer to
the existing pattern that uses env variables for matrix values and update the
step that currently references matrix.suite_name).

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

Push a commit to this branch (recommended)
Create a new PR with the fixes

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: aaccc71e-98cb-464c-aac8-1a423ff16481

📥 Commits

Reviewing files that changed from the base of the PR and between 24b50e8 and 0ed8ebd.

📒 Files selected for processing (3)

.github/workflows/benchmark.yml
react_on_rails_pro/spec/dummy/db/seeds.rb
react_on_rails_pro/spec/dummy/spec/requests/posts_page_spec.rb

🚧 Files skipped from review as they are similar to previous changes (2)

react_on_rails_pro/spec/dummy/spec/requests/posts_page_spec.rb
react_on_rails_pro/spec/dummy/db/seeds.rb

claude · 2026-06-05T02:22:41Z

Code Review — PR #3615

Root cause analysis and fix are solid. The PR correctly identifies that /posts_page is the only synchronous DB-backed benchmark route and that db:prepare never ran before server start. The approach — deterministic seeds + pre-flight db:prepare + post-seed assertion — is minimal and well-targeted.

Workflow (`.github/workflows/benchmark.yml`)

SECRET_KEY_BASE is set at job level, so rails runner initializing the full app in production mode will work without extra config.
The if: matrix.server_kind == 'rails' && matrix.pro_env == 'true' condition correctly targets only the Pro Rails suite (confirmed via generate_matrix.rb where pro_env is serialized with .to_s).
The post-seed abort() guard is a good safety net — an empty table would otherwise silently appear healthy.
Minor: NODE_ENV: production in the env block is harmless but unused by rails db:prepare/rails runner. No action needed.

Seeds (`db/seeds.rb`)

Two minor issues worth addressing:

1. Top-level constants will produce warnings on re-load. USER_COUNT, POSTS_PER_USER, COMMENTS_PER_POST, and LOREM are defined in Object scope. Since rails db:seed uses load (not require), running seeds a second time in a dev console will print warning: already initialized constant USER_COUNT etc. Wrapping in a private scope or using unless defined? guards would suppress this. See inline comment.

2. POSTS_PER_USER.size as a cycle modulo is correct but fragile. For (3..7), .size returns 5 and .first returns 3, so 3 + (idx % 5) correctly cycles through 3–7. The arithmetic breaks if the range is ever changed to non-unit-step or made exclusive (3...7). See inline comment for a less surprising alternative.

Spec (`spec/requests/posts_page_spec.rb`)

The self-loading schema pattern (unless table_exists? … load schema.rb) is correct and efficient given that maintain_test_schema! is intentionally disabled in this suite.
Transactional fixtures are off, but the after block cleans up. The spec is self-sufficient.
Minor: the H1 assertion uses Nokogiri while adjacent assertions use raw string matching — slight inconsistency. See inline comment.

Overall

Fixes a real, reproducible bug with minimal blast radius. The new spec is a good guard for the specific regression class. The items above are minor polish — none are blocking.

Apply non-blocking review feedback from PR #3615 (claude, greptile, coderabbit). No behavior change — seeded data is byte-for-byte identical. - seeds.rb: replace top-level constants with local variables so re-running `rails db:seed` in an already-loaded process no longer emits `warning: already initialized constant`; cycle per-record counts through precomputed arrays so the modulo stays correct if a range is ever made exclusive or non-unit-step. - benchmark.yml: route `matrix.suite_name` through an env var in the "Prepare and seed" step (injection hardening), matching the adjacent "Execute benchmark suite" step. - posts_page_spec.rb: broaden the self-loading schema guard to check all three tables the examples touch (users/posts/comments), and document why the H1 assertion parses with Nokogiri while the title checks use substrings. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

justin808 · 2026-06-05T02:36:29Z

Review follow-up — addressed in `498045164`

Thanks for the reviews (@claude, @greptile-apps, @coderabbitai). All comments were non-blocking polish; I addressed the substantive ones in 4980451. No behavior change — the seeded dataset is byte-for-byte identical (I verified the per-record count cycling produces the same values as the previous implementation).

Addressed

seeds.rb — re-load constant warnings: converted USER_COUNT/POSTS_PER_USER/COMMENTS_PER_POST/LOREM to local variables, so re-running rails db:seed in an already-loaded process no longer prints warning: already initialized constant.
seeds.rb — fragile modulo cycling: per-record counts now cycle through precomputed arrays ((3..7).to_a, (2..5).to_a), which stays correct even if a range is later made exclusive or non-unit-step.
benchmark.yml — injection hardening: routed matrix.suite_name through a SUITE_NAME env var in the "Prepare and seed" step, matching the adjacent "Execute benchmark suite" step.
posts_page_spec.rb — schema guard: broadened the self-loading guard to check all three tables the examples touch (users/posts/comments).
posts_page_spec.rb — assertion style: kept the Nokogiri <h1> check (it asserts the heading renders specifically in an <h1>, not just anywhere in the body) and added a comment explaining why it differs from the substring title checks.

Not changed (rationale in inline replies)

ActiveRecord::Base.connection "deprecation": not deprecated in Rails 7.2.3 (this app's pin), so no warning is emitted — kept as-is.
unless defined? guards (x2): the warning is fully removed by the local-variable change above, so per-constant guards aren't needed.

Validation: ruby -c, RuboCop (Pro config), Prettier, and a YAML parse all pass; I checked seed-count determinism against the previous implementation. The full :server_rendering request spec runs in CI (it needs the Pro node renderer).

— I (Claude Code) on behalf of @justin808

coderabbitai · 2026-06-05T02:37:01Z

@justin808 Thank you for the thorough follow-up summary! All the addressed items look great:

Local variables in seeds.rb — eliminates the re-initialization warnings cleanly without needing per-constant unless defined? guards.
Precomputed arrays for cycling — more robust than raw modulo arithmetic on ranges.
SUITE_NAME env var — consistent injection hardening with the adjacent benchmark step.
Broadened schema guard — checking all three tables (users/posts/comments) is the right call.
Nokogiri <h1> assertion with doc comment — the explanation clarifies the intent nicely for future readers.

The rationale for the two non-changes is also sound:

ActiveRecord::Base.connection is not deprecated in Rails 7.2.3 in this usage pattern — no warning, no change needed.
With constants converted to local variables, the unless defined? guards are indeed redundant.

The PR looks good to merge. Approving.

(ﾉ◕ヮ◕)ﾉ*:･ﾟ✧

🧠 Learnings used

Learnt from: CR
Repo: shakacode/react_on_rails PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-06-02T08:12:16.985Z
Learning: Applies to CHANGELOG.md : Update `CHANGELOG.md` only for user-visible changes (features, bug fixes, breaking changes, deprecations, performance improvements); do not add entries for linting, formatting, refactoring, tests, or doc fixes. Format: `[PR 1818](https://github.com/shakacode/react_on_rails/pull/1818) by [username](https://github.com/username)`

Learnt from: justin808
Repo: shakacode/react_on_rails PR: 0
File: :0-0
Timestamp: 2026-04-13T02:29:20.920Z
Learning: In `react_on_rails_pro/lib/react_on_rails_pro/engine.rb` and `react_on_rails/lib/react_on_rails/configuration.rb` (PR `#3094`): Do NOT reset `rendering_strategy` or `js_code_builder` inside `ReactOnRails.configure`. The Pro engine sets these exactly once during `after_initialize`; resetting them on reconfigure would silently drop Pro's NodeStrategy/ProJsCodeBuilder assignments. A proper reconfigure mechanism for these accessors is deferred to Step 3 of the strategy-pattern refactor (`#2905`).

Learnt from: justin808
Repo: shakacode/react_on_rails PR: 3094
File: react_on_rails_pro/lib/react_on_rails_pro/js_code_builder.rb:40-64
Timestamp: 2026-04-13T02:28:35.099Z
Learning: In `react_on_rails_pro/lib/react_on_rails_pro/js_code_builder.rb`, the `typeof generateRSCPayload !== 'function'` guards in `rsc_payload_function_section` are an intentional faithful port of the existing pattern in `server_rendering_js_code.rb` (lines 21 and 39). Do not flag this guard as a bug in this file; any fix should be tracked as a separate issue covering both files.

Learnt from: ihabadham
Repo: shakacode/react_on_rails PR: 2674
File: react_on_rails/lib/react_on_rails/doctor.rb:2325-2345
Timestamp: 2026-03-19T16:13:07.375Z
Learning: In `react_on_rails/lib/react_on_rails/doctor.rb`, `check_rsc_payload_route` and `check_rsc_procfile_watcher` filter commented lines (`/^\s*`#/``) before checking for the target string, consistent with the `config_has_async_loading_strategy?` pattern. The doctor avoids a full Rails boot for resilience and uses file-content scanning instead of actual Rails route inspection. Remaining accepted limitations are dynamic/engine-mounted routes and routes loaded via the `draw` macro (uncommon, since the generator places `rsc_payload_route` directly in `config/routes.rb`).

Learnt from: justin808
Repo: shakacode/react_on_rails PR: 2651
File: docs/oss/introduction.md:47-47
Timestamp: 2026-03-26T02:20:12.940Z
Learning: In `docs/oss/introduction.md` (and related docs in the `shakacode/react_on_rails` repo), the link to `docs/oss/getting-started/comparison-with-alternatives.md` described as "a side-by-side matrix with benchmarks" is intentionally and accurately worded. The page includes actual benchmark sections (e.g., Vite vs Rspack benchmark tables), so the phrase "with benchmarks" should NOT be flagged as misleading in future reviews.

Learnt from: justin808
Repo: shakacode/react_on_rails PR: 2790
File: docs/oss/migrating/rsc-data-fetching.md:238-238
Timestamp: 2026-03-22T03:17:13.316Z
Learning: In `docs/oss/migrating/rsc-data-fetching.md` (React on Rails migration guide), the phrase "Rails fetches the data in the controller layer" is intentional and acceptable wording even when the ERB examples show inline ActiveRecord queries inside `stream_react_component`/`stream_react_component_with_async_props`. The inline queries are a teaching shortcut; "controller layer" is meant to convey that data fetching happens on the Rails side (not in React), not to mandate that queries must live in a controller action. Do not flag this phrasing as misleading in future reviews.

Learnt from: CR
Repo: shakacode/react_on_rails PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-06-02T08:12:16.985Z
Learning: Applies to react_on_rails/spec/**/*.rb : Use RSpec for Ruby unit tests in `react_on_rails/spec/react_on_rails/` and integration tests via the dummy Rails app in `react_on_rails/spec/dummy/`

Learnt from: CR
Repo: shakacode/react_on_rails PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-06-02T08:12:16.985Z
Learning: Applies to react_on_rails/Gemfile.development_dependencies : Never reintroduce conditional gem declarations like `gem "turbolinks" if ENV["DISABLE_TURBOLINKS"].nil?` in `react_on_rails/Gemfile.development_dependencies`; conditional inclusion diverges from the lockfile and breaks `bundle install --frozen` in CI

Learnt from: AbanoubGhadban
Repo: shakacode/react_on_rails PR: 2464
File: packages/react-on-rails-pro-node-renderer/src/worker.ts:343-393
Timestamp: 2026-02-21T20:46:38.404Z
Learning: In packages/react-on-rails-pro-node-renderer, the `Promise.all` pattern for per-bundle operations (e.g., in `/upload-assets` endpoint and `handleNewBundlesProvided` in handleRenderRequest.ts) is intentional. Copy operations like `copyUploadedAssets` are idempotent and retries are safe, so fast-fail behavior on lock acquisition or copy errors is acceptable. Switching to `Promise.allSettled` to surface partial success would require Ruby-side protocol changes.

Learnt from: alexeyr-ci2
Repo: shakacode/react_on_rails PR: 3448
File: .github/workflows/benchmark.yml:134-137
Timestamp: 2026-05-27T22:56:07.687Z
Learning: In `.github/workflows/benchmark.yml` (react_on_rails repo), setting `RUN_PRO_BENCHMARKS=true` when `steps.detect.outputs.run_pro_node_renderer_tests` is `true` is intentional. Node renderer changes can affect Rails performance, so Pro Rails benchmarks are deliberately triggered alongside node renderer benchmarks when node-renderer-only changes are detected.

Learnt from: CR
Repo: shakacode/react_on_rails PR: 0
File: react_on_rails_pro/CLAUDE.md:0-0
Timestamp: 2026-05-26T02:45:13.515Z
Learning: Applies to react_on_rails_pro/spec/dummy/spec/**/*.rb : Pro integration tests must be run with: `cd react_on_rails_pro/spec/dummy && bundle exec rspec spec/`

✅ Action performed

Comments resolved and changes approved.

greptile-apps · 2026-06-05T02:37:27Z

All addressed cleanly. The changes in 498045164 are correct:

seeds.rb: Local variables instead of constants is the right fix — since seeds.rb is loaded (not required), top-level constants would re-initialize on every db:seed invocation in the same process. The precomputed arrays for cycling are also more robust.
benchmark.yml: The SUITE_NAME env var routing matches the pattern established by the adjacent "Execute benchmark suite" step — consistent.
posts_page_spec.rb: Checking all three tables (users/posts/comments) in the schema guard is the right scope; a partial schema could silently pass the single-table check and blow up mid-example. The Nokogiri comment explaining why h1 differs from the substring title checks is helpful for future readers.

The rationale for the two non-changes is also sound: ActiveRecord::Base.connection isn't deprecated in 7.2.3 (that's a Rails 8.x concern), and the per-constant unless defined? guards aren't needed once the constants are gone.

LGTM on 498045164. The PR looks ready to merge.

claude · 2026-06-05T02:49:47Z

Code Review

Overall Assessment

Solid, well-scoped fix. The root cause analysis is accurate (posts table missing → 500 on every /posts_page request; streaming RSC routes hide the same failure because the 200 status line is sent before the body errors), the solution is correct, and the three-file change set is minimal and targeted.

benchmark.yml — CI step

The if: matrix.server_kind == 'rails' && matrix.pro_env == 'true' gate is precise; it only runs for the Pro Rails suite, which is the only one serving DB-backed routes.
Routing SUITE_NAME through env: before using it in echo is a good defensive habit even though the value comes from your own generate_matrix.rb.
The row-count guard is the right belt-and-suspenders check: db:prepare only seeds on first creation, so a fresh-but-unseedable DB would otherwise pass and serve a misleading "No posts found" 200.
One edge case worth knowing: if a runner already has a production DB with ≥ 1 post from a previous (partial) run, db:prepare skips re-seeding and the row-count check passes even if the data is stale. Not a concern for ephemeral GitHub Actions runners, just noting for completeness.

seeds.rb — deterministic rewrite

Clean rewrite. Using local variables (rather than constants) to avoid already initialized constant warnings when rails db:seed is re-run is a nice touch.

Nit: The block parameter p in the post body construction shadows Ruby's built-in p kernel method, which Rubocop flags as Naming/BlockParameterName:

body: Array.new(3) { |p| lorem_paragraph.call(4, seed + p) }.join("\n\n")

Rename to |para_idx| or |pi| to keep rubocop clean.

posts_page_spec.rb — new integration test

The schema-presence guard in before (load schema.rb only when a table is missing) is the right approach given that maintain_test_schema! is intentionally disabled in this suite.
force: :cascade in schema.rb means the load drops-and-recreates tables if any are missing — harmless in a single-threaded test run.
The second example ("returns 200 (not 500) when there are no posts") explicitly re-deletes all records at the start of the test body. This is intentional (clearing what before just seeded), correct, and self-documenting.
The Nokogiri::HTML assertion on the <h1> is a nice stricter check compared to a raw substring match.

Summary

No blocking issues. The one actionable nit is the |p| block parameter shadowing in seeds.rb. Everything else is correct and well-documented. The root cause, fix, and test coverage are all sound.

claude · 2026-06-05T02:50:04Z

+    seed = (user_index * 11) + post_index
+    posts << user.posts.create!(
+      title: lorem_sentence.call(3, seed),
+      body: Array.new(3) { |p| lorem_paragraph.call(4, seed + p) }.join("\n\n")


The block parameter p shadows Ruby's built-in p kernel method, which Rubocop flags under Naming/BlockParameterName. Consider renaming to para_idx or pi:

Suggested change

body: Array.new(3) { |p| lorem_paragraph.call(4, seed + p) }.join("\n\n")

body: Array.new(3) { |para_idx| lorem_paragraph.call(4, seed + para_idx) }.join("\n\n")

Address review feedback on PR #3615: - benchmark.yml: use `set -euo pipefail` and guard every table /posts_page reads (users and comments, not just posts) so a partial seed can no longer pass the benchmark job green. - Add spec/dummy/spec/db/seeds_spec.rb: loads db/seeds.rb with the Faker constant hidden (reproducing RAILS_ENV=production) and asserts the tables populate deterministically. This catches a Faker reintroduction or empty seed on every Pro dummy spec run — the layer that actually broke in #3602 previously had no automated coverage. - Trim over-verbose comments in benchmark.yml, seeds.rb, and posts_page_spec.rb. The CI-gating gap that lets Pro-dummy-only changes skip these specs is pre-existing and tracked separately in #3633. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

justin808 · 2026-06-05T03:05:07Z

Addressed multi-agent review feedback in 7e4519b. I (Claude Code) made the following changes:

Hardening (.github/workflows/benchmark.yml)

set -euo pipefail (was set -e) so the seed-count guard stays fatal even if the command is ever piped.
The guard now checks every table /posts_page reads — posts, users, and comments — not just posts. A partial seed can no longer pass the benchmark job green.

New coverage (react_on_rails_pro/spec/dummy/spec/db/seeds_spec.rb)

Loads db/seeds.rb with the Faker constant hidden (reproducing RAILS_ENV=production, where faker isn't bundled) and asserts the tables populate deterministically. This guards the layer that actually broke in Fix PostsPage Pro route #3602 — a Faker:: reintroduction or empty seed now fails on every Pro dummy spec run. Needs no node renderer, so it runs in the regular Pro dummy job. Passing locally (2 examples, 0 failures).

Comment trims — removed over-verbose comments in benchmark.yml, seeds.rb, and posts_page_spec.rb flagged as low-value.

Follow-up: the dummy integration jobs in pro-integration-tests.yml gate on run_pro_tests, which excludes PRO_DUMMY_CHANGED — so a future Pro-spec/dummy-only PR would skip these specs. Pre-existing CI gap, tracked in #3633.

claude · 2026-06-05T03:44:53Z

+          # green. `set -o pipefail` keeps this abort fatal even if the command
+          # is ever piped.
+          bundle exec rails runner 'counts = { posts: Post.count, users: User.count, comments: Comment.count }; empty = counts.select { |_, c| c.zero? }.keys; abort("Benchmark DB seeding incomplete after db:prepare (empty: #{empty.join(", ")}); seeds did not run") if empty.any?; puts "✅ Database seeded (#{counts.map { |k, v| "#{v} #{k}" }.join(", ")})"'
+


This ~250-character one-liner is correct but will be painful to read or edit later. rails runner - reads from stdin, so a heredoc keeps the YAML width manageable and the Ruby readable:

Suggested change

bundle exec rails runner - <<'RUBY'

counts = { posts: Post.count, users: User.count, comments: Comment.count }

empty = counts.select { |_, c| c.zero? }.keys

abort("Benchmark DB seeding incomplete after db:prepare (empty: #{empty.join(', ')}); seeds did not run") if empty.any?

puts "✅ Database seeded (#{counts.map { |k, v| "#{v} #{k}" }.join(', ')})"

RUBY

claude · 2026-06-05T03:45:05Z

+        # the shell), matching the "Execute benchmark suite" step below.
+        env:
+          RAILS_ENV: production
+          NODE_ENV: production


NODE_ENV isn't read by rails db:prepare or rails runner. Dropping it avoids implying this step has a Node.js dependency.

Suggested change

NODE_ENV: production

NODE_ENV: production # not needed for db:prepare/rails runner; safe to remove

Or simply omit the line entirely.

claude · 2026-06-05T03:45:11Z

+          # green. `set -o pipefail` keeps this abort fatal even if the command
+          # is ever piped.


set -euo pipefail was already set on line 410 of this block, so pipefail is already active for every subsequent command — including this one. The comment implies the flag is being applied specifically here, which is misleading. Consider removing it, since set -e at the top already covers the abort-on-error behavior for this command.

claude · 2026-06-05T03:45:45Z

Code Review

Overall: Well-structured fix with solid testing. Three minor nits in the workflow step (see inline comments).

What this PR does

Fixes a 100% 5xx rate on the /posts_page benchmark route caused by the production DB never being created or seeded before the server starts. The three-pronged approach — CI fix, deterministic seeds, regression tests — is the right level of completeness for this bug.

Strengths

Root-cause diagnosis is precise. The explanation of why streaming RSC routes masked the same missing-table error (status line flushed before body errors) is accurate and useful for future debugging.
Deterministic seeds are better than Faker for benchmarks. Reproducible payloads across CI runs means timing regressions are attributable to code changes, not data variance. The count math (10 users / 50 posts / 173 comments) checks out.
hide_const("Faker") is the right approach in seeds_spec.rb. It correctly simulates the production environment (where the gem is not loaded) without requiring a separate RAILS_ENV=production test run.
The validation step after db:prepare (checking all three tables are non-empty) is a good safety net. It converts what would be a silent benchmark-scoring-healthy-empty-page into a loud CI failure.
Using env vars to pass matrix values to the shell (SUITE_NAME: ${{ matrix.suite_name }}) rather than directly interpolating is the correct injection-safe pattern.

Issues (see inline comments for details)

Long one-liner — the rails runner guard is ~250 chars of Ruby in a shell-quoted string. Correct, but a heredoc (rails runner -) would be much easier to read and edit.
NODE_ENV: production in the DB step — not read by db:prepare or rails runner; implies a Node dependency that does not exist here.
Misleading pipefail comment — set -euo pipefail is already active from the top of the block; the comment makes it sound like the flag is specifically applied to the rails runner line.

Test coverage notes

seeds_spec.rb second example calls load_seeds twice — correct, because seeds.rb starts with delete_all, so each load starts from a clean slate. The determinism assertion on count + title order is sufficient.
posts_page_spec.rb empty-table test has an extra delete_all triple in the test body after the before block already seeded — redundant with the before state but clearly intentional and harmless.
Transactional fixtures are disabled in this suite (pre-existing), so the after-block delete_all cleanup is the right pattern here.

Summary

The fix is correct. The three issues above are all in the workflow step and are minor — the only one worth changing before merge is the one-liner (readability will matter the next time someone touches this step).

github-actions · 2026-06-05T04:18:28Z

Pro Node Renderer Benchmark Summary

Benchmark	RPS	p50(ms)	p90(ms)	Fail%	Status
Pro Node Renderer: simple_eval (non-RSC)	2158.85	4.17	5.45	0.0	200=64773
Pro Node Renderer: react_ssr (non-RSC)	1913.64	4.74	6.27	0.0	200=57418

🔴 significant regression · 🟢 significant improvement (vs baseline; tracked measures only)

github-actions · 2026-06-05T04:35:58Z

Pro (shard 1/2) Benchmark Summary

Benchmark	RPS	p50(ms)	p90(ms)	Status
/: Pro	178.72	46.57	64.62	200=5404
/error_scenarios_hub: Pro	367.07	20.73	31.26	200=11095
/ssr_async_error: Pro	283.01	20.51	56.28	200=8553
/ssr_async_prop_error: Pro	328.46	26.83	36.62	200=9862
/non_existing_react_component: Pro	354.92	15.78	30.16	200=10795
/non_existing_rsc_payload: Pro	364.55	21.5	31.78	200=11016
/cached_react_helmet: Pro	370.33	16.91	28.3	200=11193
/cached_redux_component: Pro	379.96	20.83	30.77	200=11484
/lazy_apollo_graphql: Pro	123.39	48.24	88.29	200=3731
/redis_receiver: Pro	62.84	77.16	142.32	200=2722,3xx=21
/stream_shell_error_demo: Pro	343.48	22.89	36.74	200=10378
/test_incremental_rendering: Pro	344.14	23.02	36.72	200=10400
/rsc_posts_page_over_redis: Pro	63.46	91.59	132.13	200=2707,3xx=38
/async_on_server_sync_on_client: Pro	287.63	27.0	43.38	200=8692
/server_router: Pro	320.26	24.3	36.14	200=9679
/unwrapped_rsc_route_client_render: Pro	378.0	20.18	32.97	200=11431
/async_render_function_returns_string: Pro	288.89	20.1	34.37	200=8731
/async_components_demo: Pro	206.77	39.03	52.78	200=6252
/stream_native_metadata: Pro	344.17	22.14	34.36	200=10402
/rsc_native_metadata: Pro	335.63	23.23	37.27	200=10142
/client_side_hello_world: Pro	362.89	20.93	31.56	200=10968
/client_side_hello_world_shared_store_controller: Pro	334.34	23.36	36.14	200=10100
/server_side_hello_world_shared_store: Pro	274.55	29.34	45.5	200=8246
/server_side_hello_world_shared_store_defer: Pro	271.41	32.41	41.79	200=8201
/server_side_hello_world_hooks: Pro	346.47	18.27	30.49	200=10473
/server_side_log_throw: Pro	344.62	22.71	34.46	200=10415
/server_side_log_throw_raise: Pro	663.58	11.94	18.38	3xx=20043
/server_side_hello_world_es5: Pro	338.37	23.32	35.87	200=10225
/server_side_hello_world_with_options: Pro	340.7	22.94	34.04	200=10297
/client_side_manual_render: Pro	377.46	20.41	30.32	200=11407
/react_router: Pro	399.74	18.58	33.04	200=12076
/css_modules_images_fonts_example: Pro	343.58	25.5	33.96	200=10381
/rendered_html: Pro	340.44	25.66	35.27	200=10220
/react_helmet: Pro	319.54	24.83	38.53	200=9660
/image_example: Pro	289.92	19.46	35.7	200=8819
/posts_page: Pro	78.17 🔴	103.78 🔴	127.65	200=2366

🔴 significant regression · 🟢 significant improvement (vs baseline; tracked measures only)

github-actions · 2026-06-05T04:37:16Z

Pro (shard 2/2) Benchmark Summary

Benchmark	RPS	p50(ms)	p90(ms)	Status
/empty: Pro	1320.84	6.03	8.73	200=39900
/ssr_shell_error: Pro	314.18	18.12	21.99	200=9557
/ssr_sync_error: Pro	366.67	21.12	33.65	200=11080
/rsc_component_error: Pro	338.07	22.97	34.46	200=10215
/non_existing_stream_react_component: Pro	365.2	9.22	27.69	200=11111
/server_side_redux_app_cached: Pro	340.41	16.97	39.42	200=10286
/loadable: Pro	286.27	19.82	23.55	200=8653
/apollo_graphql: Pro	152.3	46.84	69.94	200=4607
/console_logs_in_async_server: Pro	3.16	2119.36	2146.94	200=108
/stream_error_demo: Pro	296.77	19.09	23.55	200=9029
/stream_async_components: Pro	294.24	19.59	45.89	200=8890
/rsc_posts_page_over_http: Pro	295.06	19.56	64.12	200=8917
/rsc_echo_props: Pro	242.76	32.99	51.1	200=7337
/async_on_server_sync_on_client_client_render: Pro	311.05	18.55	31.08	200=9402
/server_router_client_render: Pro	368.64	21.07	32.59	200=11137
/unwrapped_rsc_route_stream_render: Pro	372.97	20.05	35.64	200=11271
/async_render_function_returns_component: Pro	361.7	21.61	33.55	200=10926
/native_metadata: Pro	335.65	23.7	35.48	200=10141
/hybrid_metadata_streaming: Pro	351.86	21.5	33.31	200=10634
/cache_demo: Pro	287.17	19.66	25.76	200=8736
/client_side_hello_world_shared_store: Pro	298.57	19.27	32.52	200=9023
/client_side_hello_world_shared_store_defer: Pro	364.82	15.11	28.69	200=11099
/server_side_hello_world_shared_store_controller: Pro	249.45	19.1	26.87	200=7590
/server_side_hello_world: Pro	342.71	22.54	34.2	200=10360
/client_side_log_throw: Pro	349.43	24.83	33.01	200=10558
/server_side_log_throw_plain_js: Pro	412.14	19.2	30.06	200=12451
/server_side_log_throw_raise_invoker: Pro	437.54	17.61	25.74	200=13220
/server_side_redux_app: Pro	346.27	22.77	35.93	200=10465
/server_side_redux_app_cached: Pro	373.98	21.07	32.44	200=11300
/render_js: Pro	365.47	21.33	34.43	200=11044
/pure_component: Pro	273.45	21.04	25.33	200=8266
/turbolinks_cache_disabled: Pro	355.14	21.24	32.2	200=10733
/xhr_refresh: Pro	216.73	26.58	38.6	200=6551
/broken_app: Pro	326.32	17.09	32.32	200=9926
/server_render_with_timeout: Pro	331.62	23.7	37.16	200=10023

🔴 significant regression · 🟢 significant improvement (vs baseline; tracked measures only)

github-actions · 2026-06-05T04:37:44Z

Core Benchmark Summary

Benchmark	RPS	p50(ms)	p90(ms)	Status
/: Core	3.0	2987.72	3385.42	200=98
/client_side_hello_world: Core	724.77	9.07	21.67	200=21894
/client_side_rescript_hello_world: Core	688.29	8.82	21.85	200=20793
/client_side_hello_world_shared_store: Core	476.6	12.32	20.99	200=14399
/client_side_hello_world_shared_store_controller: Core	675.99	10.05	19.77	200=20421
/client_side_hello_world_shared_store_defer: Core	695.35	9.32	23.43	200=21005
/server_side_hello_world_shared_store: Core	12.67	643.34	905.25	200=390
/server_side_hello_world_shared_store_controller: Core	12.74	711.97	873.46	200=391
/server_side_hello_world_shared_store_defer: Core	12.57	684.49	870.35	200=385
/server_side_hello_world: Core	26.41	316.94	385.76	200=803
/server_side_hello_world_hooks: Core	26.24	308.95	375.08	200=801
/server_side_hello_world_props: Core	19.85	299.01	364.95	200=608
/client_side_log_throw: Core	476.39	12.31	16.62	200=14394
/server_side_log_throw: Core	25.44	321.89	392.02	200=776
/server_side_log_throw_plain_js: Core	25.83	319.83	395.18	200=784
/server_side_log_throw_raise: Core	22.16	251.99	268.88	3xx=683
/server_side_log_throw_raise_invoker: Core	801.19	7.91	16.6	200=24207
/server_side_hello_world_es5: Core	26.37	315.7	379.03	200=803
/server_side_redux_app: Core	24.98	332.0	401.0	200=761
/server_side_hello_world_with_options: Core	26.23	324.03	383.45	200=798
/server_side_redux_app_cached: Core	739.62	10.11	18.07	200=22343
/client_side_manual_render: Core	692.6	9.01	19.14	200=20927
/render_js: Core	27.53	213.58	348.96	200=843
/react_router: Core	24.78	333.64	400.63	200=756
/pure_component: Core	26.03	252.31	373.04	200=796
/css_modules_images_fonts_example: Core	20.22	298.59	472.65	200=616
/turbolinks_cache_disabled: Core	697.99	8.96	18.99	200=21088
/rendered_html: Core	26.58	314.01	380.16	200=807
/xhr_refresh: Core	13.32	639.37	810.71	200=409
/react_helmet: Core	25.52	325.28	395.6	200=776
/broken_app: Core	25.52	326.8	397.14	200=777
/image_example: Core	25.86	322.33	393.37	200=785
/turbo_frame_tag_hello_world: Core	781.59	10.45	18.46	200=23610
/manual_render_test: Core	718.59	9.1	22.55	200=21707

🔴 significant regression · 🟢 significant improvement (vs baseline; tracked measures only)

* origin/main: (21 commits) docs(benchmarks): archive RSC FOUC ShakaPerf investigation feat(generator): scaffold native RSCRspackPlugin for rspack RSC fix(pro): admit react-on-rails-rsc RC prereleases in peer range ci(benchmarks): richer summary table fix(benchmarks): seed Pro dummy DB so /posts_page stops 500ing (#3602) (#3615) fix(benchmark): detect backgrounded server/renderer crashes during readiness and benchmark (#3579) refactor: harden ShakapackerConfigHelpers module (#3626) (#3629) fix: classify renderer connection failures separately from bundle errors (#3614) Align docs demo naming and version guidance (#3598) Harden async props pending specs (#3600) docs(ci): link latest/minimum coupling comment to tracking issue #3622 (#3623) Use probe-only route for ShakaPerf FOUC gate (#3630) [codex] Add ShakaPerf RSC FOUC release gate (#3617) refactor: consolidate Shakapacker bundler/config diagnostics helpers (#3619) docs(pro): document CI pattern for renderer-backed Rails tests (#3612) Update RSC rollout to react-on-rails-rsc 19.0.5-rc.6 (#3577) fix(pro): polish rolling-deploy auto-route prefix + hash constraint (#3548) (#3611) fix(pro): log unmountComponentAtNode teardown failure at error level (#3592) (#3610) ci(rspack): decouple per-bundler build + integration jobs so one bundler's build failure doesn't skip the other (#3593) (#3613) ci: stop benchmarks/tests running on internal-docs & issue-template-only PRs (#3608) ... # Conflicts: # CHANGELOG.md

coderabbitai Bot added review-needed full-ci benchmark P2 Backlog priority labels Jun 4, 2026

greptile-apps Bot reviewed Jun 4, 2026

View reviewed changes

Comment thread react_on_rails_pro/spec/dummy/db/seeds.rb Outdated

Comment thread react_on_rails_pro/spec/dummy/spec/requests/posts_page_spec.rb Outdated

coderabbitai Bot reviewed Jun 4, 2026

View reviewed changes

coderabbitai Bot approved these changes Jun 4, 2026

View reviewed changes

claude Bot reviewed Jun 4, 2026

View reviewed changes

Comment thread react_on_rails_pro/spec/dummy/db/seeds.rb Outdated

claude Bot reviewed Jun 4, 2026

View reviewed changes

Comment thread react_on_rails_pro/spec/dummy/spec/requests/posts_page_spec.rb Outdated

justin808 and others added 2 commits June 4, 2026 16:08

justin808 force-pushed the jg-conductor/3602-fix branch from 24b50e8 to 0ed8ebd Compare June 5, 2026 02:09

justin808 mentioned this pull request Jun 5, 2026

Add streaming RSC posts-route coverage (200-with-broken-body masks benchmark failures) #3625

Closed

coderabbitai Bot requested changes Jun 5, 2026

View reviewed changes

Comment thread .github/workflows/benchmark.yml Outdated