Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (3)
Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review. 📝 WalkthroughWalkthroughThe first-page parameter selection now preserves a stored ChangesInfinite-query refetch behavior
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix Merge Risk: ⚪ Minimal · up to The refetch behavior is covered by the new regression test, with no remaining concrete merge-blocking risk identified. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 2 files. (1 skipped: 1 unsupported.) ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
🎯 Changes
Infinite-query refetches reuse the stored first
pageParam, falling back to the currentinitialPageParamonly when no stored value exists. The implementation used??, so a valid storednullpage parameter was treated as missing and replaced wheninitialPageParamlater changed.initialPageParamonly when the stored first page parameter isundefined.null, changesinitialPageParam, and verifies the refetch still uses the storednullvalue.@tanstack/query-core.Validation:
pnpm run test:prwith Node 24.16.0 (209 tasks passed).✅ Checklist
pnpm run test:pr, or these tests do not apply to this pull request.🚀 Release Impact
Summary by CodeRabbit
nullfirst-page parameter when refetched, even if a different initial parameter is provided.