Skip to content

Add comprehensive tests for QueryCollection error handling edge cases #540

@KyleAMathews

Description

@KyleAMathews

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
  • errorCount increments 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 bump errorCount
  • 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 calls refetch()

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)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions