-
Notifications
You must be signed in to change notification settings - Fork 106
Open
Labels
Description
Relates to: PR #441 ("add error tracking and retry methods to query collection utils")
Scope: Testing / reliability
Breaking changes: None (tests only)
Summary
PR #441 added error tracking methods but several edge cases lack test coverage. This issue proposes comprehensive tests to ensure robust error handling behavior.
Missing Test Coverage
1. clearError() throwing behavior
-
clearError()throws when refetch fails -
errorCountincrements once per terminal failure (after retries) - Error state is properly restored when
clearError()fails
2. Error count precision
- No double-count on same
errorUpdatedAt: multiple observer emissions with identical timestamp do not bumperrorCount - Error count resets to 0 on successful query
- Error count persists across multiple failed retries within same attempt
3. Exact filter targeting (depends on #537)
- Exact filter targeting: sibling queries with shared prefixes are not refetched
-
refetch()only affects the specific queryKey, not parent or sibling keys -
clearError()uses exact targeting since it callsrefetch()
4. Disabled/unobserved query behavior (depends on #537)
- Disabled/unobserved behavior: with
type: 'active',clearError()/refetch()is a no-op and does not throw unless configured otherwise - Disabled queries don't increment error count when they would normally fail
- Unobserved queries handle error state correctly
5. Recovery state tracking (if implemented in #539)
-
isRecovering()(if added) toggles true → false around the retry window - Recovery state is cleared on both success and failure
- Multiple concurrent
clearError()calls handle recovery state correctly
6. Timing and concurrency
- Concurrent
clearError()calls don't create race conditions - Error state consistency during overlapping refetch operations
- Observer updates during error recovery maintain correct state
Test Structure
describe('QueryCollection error handling edge cases', () => {
describe('clearError() behavior', () => {
it('throws when refetch fails')
it('increments errorCount only once per terminal failure')
it('restores error state when clearError fails')
})
describe('error count precision', () => {
it('does not double-count on same errorUpdatedAt')
it('resets to 0 on successful query')
})
describe('exact targeting', () => {
it('does not refetch sibling queries with shared prefixes')
it('clearError uses exact targeting')
})
describe('disabled/unobserved queries', () => {
it('is no-op with type: active when disabled')
it('handles unobserved query errors correctly')
})
describe('concurrency and timing', () => {
it('handles concurrent clearError calls')
it('maintains state consistency during overlapping operations')
})
})Acceptance Criteria
- All edge cases listed above have dedicated test coverage
- Tests verify both success and failure scenarios
- Mock queryClient behavior to simulate various error conditions
- Tests are isolated and don't depend on external timing
- Cover both optimistic and reset-on-success timing semantics (if Clarify QueryCollection clearError() timing semantics #539 is implemented)