Handle fire-and-forget RSCRoute retry failures

[justin808]

Summary

Fixes #4330.

Production RSCRoute recover-on-error retries preserve the previous route content, but a fire-and-forget caller could still leave the returned retry promise unhandled after the route recorded the recoverable error. This keeps the caller-visible promise rejected while attaching an internal no-op rejection handler in production recover-on-error mode.

Changes

• Preserve the existing refetch/retry rejected promise contract for callers that await or catch it.
• Add a production recover-on-error handler so fire-and-forget retry failures do not surface as unhandled rejections.
• Add a regression test that retries from inline controls without catching the retry promise and asserts no unhandledRejection is emitted.

Validation

• pnpm --filter react-on-rails-pro exec jest tests/imperativeRefetch.client.test.tsx --runInBand
• pnpm --filter react-on-rails-pro run type-check
• pnpm exec prettier --check packages/react-on-rails-pro/src/RSCRoute.tsx packages/react-on-rails-pro/tests/imperativeRefetch.client.test.tsx
• pnpm exec eslint packages/react-on-rails-pro/src/RSCRoute.tsx packages/react-on-rails-pro/tests/imperativeRefetch.client.test.tsx --no-warn-ignored
• script/check-pro-license-headers
• git diff --check origin/main...HEAD
• codex review --base origin/main

No changelog entry: internal Pro client robustness fix with no public API change.

[coderabbitai]

Warning

Review limit reached

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

Next review available in: 10 minutes

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

How can I continue?

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

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

How do review limits work?

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

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

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: f09e8fbc-9039-4c41-9240-4b23f4ea1d82

📥 Commits

Reviewing files that changed from the base of the PR and between e03a4ad and a17d813.

📒 Files selected for processing (2)

• packages/react-on-rails-pro/src/RSCRoute.tsx
• packages/react-on-rails-pro/tests/imperativeRefetch.client.test.tsx

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch codex/batch-e-pro-route

---

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

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[justin808]

+ci-status

[justin808]

+ci-run-hosted

[github-actions]

CI Status

Head SHA: 43b57358d92b
Changed files: 2
Docs-only heuristic (matches ci-changes-detector metadata paths): no
ready-for-hosted-ci label: absent
force-full-hosted-ci label: absent
Current hosted-CI waiver: not present for this SHA

Only the required gate is active unless hosted CI is requested.

[github-actions]

Hosted CI Requested

Triggered 9 workflow(s) for 43b57358d92b.
Mode: optimized hosted CI (path-selected by script/ci-changes-detector).
Added ready-for-hosted-ci, so future commits will keep running optimized hosted CI until +ci-stop-hosted is used.

View progress in the Actions tab.

[greptile-apps]

Greptile Summary

This PR updates production retry handling for RSCRoute. The main changes are:

• Adds an internal no-op rejection handler for recover-on-error refetches.
• Keeps the returned refetch and retry promise rejected for callers that await it.
• Adds a regression test for inline fire-and-forget retry failures.

Confidence Score: 5/5

This looks safe to merge.

• No blocking issues found in the changed code.
• The returned promise still rejects because the swallowed continuation is separate from the promise returned to callers.
• The new test cleans up its rejection listener, and the existing test lifecycle restores NODE_ENV.

Important Files Changed

Filename	Overview
packages/react-on-rails-pro/src/RSCRoute.tsx	Adds production-only suppression for unhandled fire-and-forget retry rejections while preserving caller-visible rejection behavior.
packages/react-on-rails-pro/tests/imperativeRefetch.client.test.tsx	Adds inline retry controls and a regression test for production fire-and-forget retry failures.

_{Reviews (1): Last reviewed commit: "Avoid unhandled RSCRoute retry rejection..." | Re-trigger Greptile}

[github-actions]

size-limit report 📦

Path	Size
react-on-rails/client bundled (gzip)	63.51 KB (0%)
react-on-rails/client bundled (gzip) (time)	63.51 KB (0%)
react-on-rails/client bundled (brotli)	54.51 KB (0%)
react-on-rails/client bundled (brotli) (time)	54.51 KB (0%)
react-on-rails-pro/client bundled (gzip)	64.54 KB (0%)
react-on-rails-pro/client bundled (gzip) (time)	64.54 KB (0%)
react-on-rails-pro/client bundled (brotli)	55.53 KB (0%)
react-on-rails-pro/client bundled (brotli) (time)	55.44 KB (-0.17% 🔽)
registerServerComponent/client bundled (gzip)	75.91 KB (+0.03% 🔺)
registerServerComponent/client bundled (gzip) (time)	75.91 KB (+0.03% 🔺)
registerServerComponent/client bundled (brotli)	65.4 KB (-0.03% 🔽)
registerServerComponent/client bundled (brotli) (time)	65.4 KB (-0.03% 🔽)
wrapServerComponentRenderer/client bundled (gzip)	68.37 KB (0%)
wrapServerComponentRenderer/client bundled (gzip) (time)	68.37 KB (0%)
wrapServerComponentRenderer/client bundled (brotli)	58.76 KB (0%)
wrapServerComponentRenderer/client bundled (brotli) (time)	58.76 KB (0%)

[justin808]

Rebased onto origin/main b194bb67f after main advanced.

Post-rebase validation:

• pnpm --filter react-on-rails-pro exec jest tests/imperativeRefetch.client.test.tsx --runInBand
• pnpm --filter react-on-rails-pro run type-check
• git diff --check origin/main...HEAD

[claude]

Review

What this PR does: Fixes fire-and-forget RSCRoute retry/refetch calls surfacing as unhandled promise rejections in production recover-on-error mode. The returned promise (handledRefetchPromise) still rejects so callers that await/.catch() it keep working exactly as before; when recoverOnError is true, an additional no-op .catch(() => undefined) is attached to the same promise object before it's returned. Since a promise only needs one attached handler (by the end of the microtask turn) to be marked handled by the runtime, this suppresses the unhandledRejection event regardless of whether the caller ever consumes the promise, without altering what callers observe.

Review findings: I traced this fix line-by-line, checked the removed/changed control flow against the previous behavior, and checked other call sites of refetch()/retry() in boundedCacheProvider.client.test.tsx and inlineRefreshButton.client.test.tsx to confirm existing .rejects.toThrow(...)-style assertions are unaffected (multiple handlers can coexist on the same promise). No correctness bugs, regressions, or security concerns found:

• The extra handler is correctly gated on recoverOnError (production only), preserving the documented dev-mode-stays-loud behavior.
• Ordering is correct: setRefetchErrorState runs synchronously inside the original .catch before the re-thrown error propagates to the new no-op handler, so state updates aren't affected by the fix.
• The new regression test (1d4.) is well-targeted — it drives the retry through a real fire-and-forget UI handler (onClick={() => void retry()}, no .catch), asserts zero unhandledRejection events via a scoped process.on(...)/process.off(...) listener, and correctly restores NODE_ENV via the existing afterEach hook.
• This is a general fix at the right altitude (inside RSCRoute's shared refetch implementation, which retry aliases) rather than a per-callsite bandaid, so it protects all current and future fire-and-forget callers of useCurrentRSCRoute().refetch()/retry().

No blocking issues. Nice, narrowly-scoped fix with good test coverage.