Skip to content

Conversation

@shinseongsu
Copy link

@shinseongsu shinseongsu commented Jan 18, 2026

When using refetchOnMount: false with pre-cached data, the first setQueryData call would incorrectly trigger a Suspense fallback. This happened because the Proxy handler was calling queryResource() even when cached data was available.

This fix ensures that:

  1. The resource resolves immediately when data is already available, regardless of the isLoading state
  2. The Proxy handler returns cached data directly when isFetching is false and data exists, avoiding unnecessary resource access

Issue #9883

Changes

  • useBaseQuery.ts (line 263): Added || observerResult.data !== undefined condition to resolve the resource immediately when cached data exists, even if isLoading is true
    • useBaseQuery.ts (line 378-390): Modified the Proxy handler to check isFetching state before accessing queryResource(). When isFetching is false and data exists in either state or observerResult, return it directly without triggering Suspense
    • suspense.test.tsx: Added test case to verify that Suspense is never triggered when using refetchOnMount: false with pre-cached data, including initial render and subsequent setQueryData calls

Checklist

  • I have followed the steps in the Contributing guide.
  • I have tested this code locally with pnpm run test:pr.

🚀 Release Impact

  • This change affects published code, and I have generated a changeset.
  • This change is docs/CI/dev-only (no release).

Summary by CodeRabbit

  • Bug Fixes

    • Improved cached data handling to prevent unnecessary loading states during query operations with refetchOnMount disabled.
    • Refined data accessor logic to return cached data from the most up-to-date source when not actively fetching.
  • Tests

    • Added test coverage verifying that suspense is not triggered when updating pre-cached data.

✏️ Tip: You can customize this high-level summary in your review settings.

When using `refetchOnMount: false` with pre-cached data, the first
`setQueryData` call would incorrectly trigger a Suspense fallback.
This happened because the Proxy handler was calling `queryResource()`
even when cached data was available.

This fix ensures that:
1. The resource resolves immediately when data is already available,
   regardless of the `isLoading` state
2. The Proxy handler returns cached data directly when `isFetching`
   is false and data exists, avoiding unnecessary resource access

Closes TanStack#9883

Co-Authored-By: Claude Opus 4.5 <[email protected]>
@changeset-bot
Copy link

changeset-bot bot commented Jan 18, 2026

⚠️ No Changeset found

Latest commit: e825bdf

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

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Jan 18, 2026

Caution

Review failed

The pull request is closed.

📝 Walkthrough

Walkthrough

Introduces a test case verifying that suspense is not triggered when setQueryData updates pre-cached data with refetchOnMount: false. Additionally, refines the hydration promise resolution and data accessor logic in useBaseQuery to prioritize returning data when available, even if loading state would previously have blocked it.

Changes

Cohort / File(s) Summary
Test Case
packages/solid-query/src/__tests__/suspense.test.tsx
New test validates that suspense is not triggered when setQueryData mutates cached data while refetchOnMount is false; uses a suspense counter to assert no suspense boundary is entered across mutations.
Query Hydration & Data Accessor
packages/solid-query/src/useBaseQuery.ts
Modified hydration promise resolution to allow early completion when observerResult.data is defined, not just when loading is false. Refined data accessor logic to return state.data or observerResult.data when not fetching, with fallback to queryResource().data, adding distinction between isFetching and isLoading states.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

Suggested labels

package: solid-query

Suggested reviewers

  • TkDodo

Poem

🐰 With whiskers twitched and careful thought,
We cache the data that we've caught,
No suspense shall block our way,
When hydration knows the data's say,
The promise resolves, the logic's right,
Solid queries shine so bright! ✨

✨ Finishing touches
  • 📝 Generate docstrings

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.

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