* Simulate the exact retry scheduling logic from doFetch's catch block. * This reproduces the code path that caused the infinite retry loop bug. * Returns whether a retry was scheduled (true) or retries were exhausted (false).
(
queryKey: readonly unknown[],
maxRetries: number,
)
| 630 | * Returns whether a retry was scheduled (true) or retries were exhausted (false). |
| 631 | */ |
| 632 | simulateFailedFetch( |
| 633 | queryKey: readonly unknown[], |
| 634 | maxRetries: number, |
| 635 | ): { retryScheduled: boolean; retryCount: number } { |
| 636 | const key = serializeQueryKey(queryKey) |
| 637 | const currentRetries = retryCounts.get(key) ?? 0 |
| 638 | |
| 639 | if (currentRetries < maxRetries && (cache.refCounts.get(key) ?? 0) > 0) { |
| 640 | const next = currentRetries + 1 |
| 641 | retryCounts.set(key, next) |
| 642 | |
| 643 | inFlight.delete(key) |
| 644 | setQueryFetching(key, false) |
| 645 | |
| 646 | // This is the fixed line — uses clearRetryTimeout instead of clearRetryState |
| 647 | clearRetryTimeout(key) |
| 648 | |
| 649 | // Don't actually schedule a setTimeout in tests, just record the intent |
| 650 | return { retryScheduled: true, retryCount: next } |
| 651 | } |
| 652 | |
| 653 | retryCounts.set(key, 0) |
| 654 | |
| 655 | const existingEntry = getCacheEntry(key) |
| 656 | setCacheEntry(key, { |
| 657 | data: existingEntry?.data, |
| 658 | dataUpdatedAt: existingEntry?.dataUpdatedAt ?? 0, |
| 659 | error: new Error('Simulated fetch error'), |
| 660 | errorUpdatedAt: Date.now(), |
| 661 | }) |
| 662 | |
| 663 | inFlight.delete(key) |
| 664 | setQueryFetching(key, false) |
| 665 | |
| 666 | return { retryScheduled: false, retryCount: 0 } |
| 667 | }, |
| 668 | } |
nothing calls this directly
no test coverage detected