fix(react-query-4,react-query-5): disable retry in QueriesHydration s…

[rjsdnql123]

Hi Suspensive team,
Thanks for the great library!

Overview

Issue #1895

What

Force retry: 0 when calling fetchQuery and fetchInfiniteQuery in QueriesHydration.

Why

If retries occur during server-side prefetching, the server component rendering becomes blocked for each retry attempt.

How

Explicitly set retry to 0 for all query calls:

fetchQuery({ ...query, retry: 0 })
fetchInfiniteQuery({ ...query, retry: 0 })

PR Checklist

• I did below actions if need

1. I read the Contributing Guide
2. I added documents and tests.

[changeset-bot]

⚠️ No Changeset found

Latest commit: d23fe4e

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[coauthors]

People can be co-author:

Candidate	Reasons	Count	Add this as commit message
@rjsdnql123	#1948 (comment) #1948 (comment) #1948 (review) #1948 (review) #1948	5	Co-authored-by: rjsdnql123 <61114705+rjsdnql123@users.noreply.github.com>
@marshallku	#1948 (comment) #1948 (comment) #1948 (review) #1948 (review)	4	Co-authored-by: marshallku <33550065+marshallku@users.noreply.github.com>
@codecov-commenter	#1948 (comment)	1	Co-authored-by: codecov-commenter <65553080+codecov-commenter@users.noreply.github.com>
@gwansikk	#1948 (comment)	1	Co-authored-by: gwansikk <39869096+gwansikk@users.noreply.github.com>

[vercel]

@rjsdnql123 is attempting to deploy a commit to the Toss Team on Vercel.

A member of the Team first needs to authorize it.

[marshallku]

How about adding this option just on the server side?
Current solution would work both client and server side.

[rjsdnql123]

QueriesHydration is an async function component that runs only on the server. If it is used in a client component ('use client'), it will cause an async component rendering error.

Therefore, retry: 0 is applied only on the server side, while useQuery on the client follows its own retry configuration:

1. Server: fetchQuery({ retry: 0 }) → stops immediately after the first failure
2. Client: skipSsrOnError → useQuery mounts and retries based on its own retry settings

I might have misunderstood the review, so please feel free to correct me if anything is off.
I also tested this scenario, and confirmed that retries on the client are working as expected. If you could share the specific case you're referring to, I’d be happy to test it as well.

[rjsdnql123]

@marshallku : )

[marshallku]

Sorry for being late @rjsdnql123
If so, I think this is quite proper change.
How about you @manudeli

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.26%. Comparing base (eec5fc2) to head (d23fe4e).
⚠️ Report is 14 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##           main    #1948       +/-   ##
=========================================
+ Coverage      0   93.26%   +93.26%     
=========================================
  Files         0       42       +42     
  Lines         0      668      +668     
  Branches      0      166      +166     
=========================================
+ Hits          0      623      +623     
- Misses        0       42       +42     
- Partials      0        3        +3     

Components	Coverage Δ
@suspensive/react	100.00% <ø> (∅)
@suspensive/react-query	95.83% <ø> (∅)
@suspensive/react-query-4	100.00% <100.00%> (∅)
@suspensive/react-query-5	100.00% <100.00%> (∅)
@suspensive/jotai	100.00% <ø> (∅)
@suspensive/codemods	81.60% <ø> (∅)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[gwansikk]

I think if a user explicitly sets retry, we should respect that setting. TanStack Query takes the same stance — it defaults retry to 0 on the server, but if the user provides an explicit value, it follows that instead.

That said, QueriesHydration sits one layer of abstraction above TanStack Query — it always runs on the server (since it's an async component) and acts as a wrapper around fetchQuery. Given this narrower context, I do think there's room to justify enforcing SSR safety more proactively here.

Still, silently overriding a user's explicit retry value can make debugging harder. What if we exposed this as a prop instead, so the user can opt in consciously? For example, a disableRetryOnServer prop would let users make an intentional choice about the behavior they want.

What do you think? @manudeli @kangju2000 @marshallku

KOR

제 생각에는 사용자가 `retry`를 명시했다면 이를 이행하는 것이 맞다고 생각합니다. TanStack Query도 동일한 설정이에요. 서버에서 retry default를 0으로 보장하지만, 사용자가 명시한 경우엔 그 설정을 따릅니다.

다만 QueriesHydration은 TanStack Query 위에 한 단계 추상화되어 있고, 항상 서버에서만 실행되며 (async component) fetchQuery를 호출하는 wrapper라는 컨텍스트를 가지고 있어요. 그래서 SSR 안전성을 더 적극적으로 보장하는 게 정당화될 여지는 있다고 생각해요.

그럼에도 사용자 명시값을 override하는 건 디버깅을 어렵게 만들 수 있어서, props로 사용자가 선택할 수 있게 노출하는 방향은 어떨까요? 예를 들어 disableRetryOnServer 같은 prop을 두면 사용자가 의식하고 의도한 대로 동작을 선택할 수 있습니다.

어떻게 생각하세요?