docs(reference/QueryCache): clarify fetchFailureCount availability in onError callback#10724
Conversation
… onError callback
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
📝 WalkthroughWalkthroughUpdated QueryCache docs: the ChangesQueryCache onError Handler Documentation
Estimated Code Review Effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
|
View your CI Pipeline Execution ↗ for commit a5ef57f
☁️ Nx Cloud last updated this comment at |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
docs/reference/QueryCache.md (1)
46-46: ⚡ Quick winImprove clarity: specify "failed attempts" rather than "attempts".
The phrase "how many attempts were made" could be slightly ambiguous. Consider clarifying that it specifically counts failed attempts.
📝 Suggested wording improvement
- - `query.state.fetchFailureCount` indicates how many attempts were made (including retries), which can be used to differentiate a first failure from a failure after retries. + - `query.state.fetchFailureCount` indicates how many failed attempts were made (including retries), which can be used to differentiate a first failure from a failure after retries.🤖 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 `@docs/reference/QueryCache.md` at line 46, The sentence about query.state.fetchFailureCount is ambiguous—update the wording to say it counts failed attempts rather than generic attempts; specifically change the line containing `query.state.fetchFailureCount` to read something like "`query.state.fetchFailureCount` indicates how many failed fetch attempts were made (including retries), which can be used to differentiate a first failure from a failure after retries." Ensure the phrase "failed attempts" replaces "attempts" and keep the rest of the explanation intact.
🤖 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 `@docs/reference/QueryCache.md`:
- Line 46: The sentence about query.state.fetchFailureCount is ambiguous—update
the wording to say it counts failed attempts rather than generic attempts;
specifically change the line containing `query.state.fetchFailureCount` to read
something like "`query.state.fetchFailureCount` indicates how many failed fetch
attempts were made (including retries), which can be used to differentiate a
first failure from a failure after retries." Ensure the phrase "failed attempts"
replaces "attempts" and keep the rest of the explanation intact.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: f076a59f-b330-4a25-9c6a-2f562900023a
📒 Files selected for processing (1)
docs/reference/QueryCache.md
1 participant
🎯 Changes
The
queryparameter passed toQueryCache'sonErrorcallback already exposesquery.state.fetchFailureCount, which reflects the total number of failed attempts(initial + retries). However, this was not documented, leading users to believe retry
attempt count was inaccessible in error callbacks (see #10713).
queryparameter usage with a practical retry-count checkonErroroption description aboutfetchFailureCount✅ Checklist
pnpm run test:pr.🚀 Release Impact
Summary by CodeRabbit