[svelte-query] Reactive options updates can cancel and restart an in-flight refetch without changing the query key or enabled value

[IdrisCelik]

Describe the bug

With createInfiniteQuery, updating reactive state used by the options accessor can cancel and restart an in-flight refetch, even though:

• The query key stays the same.
• enabled remains true.
• The QueryClient stays the same.
• The component remains mounted.
• No explicit cancellation or invalidation occurs.

For example, replacing reactive state { enabled: true } with a new { enabled: true } object during a focus-triggered refetch can abort the current request and restart fetching from the first page.

With two cached pages, the reproduction fetches pages [0, 0, 1] instead of [0, 1]. The first request's AbortSignal becomes aborted.

Your minimal, reproducible example

See tests below

Steps to reproduce

The regression test below uses only Svelte, TanStack Query and Vitest. Run it as a .svelte.test.ts file in a Svelte-enabled Vitest setup using the client/browser resolution conditions and jsdom.

import { expect, it, vi } from 'vitest'
import { flushSync } from 'svelte'
import {
  QueryClient,
  InfiniteQueryObserver,
  createInfiniteQuery,
  infiniteQueryOptions,
  focusManager,
} from '@tanstack/svelte-query'

it('does not cancel a refetch when reactive options retain the same values', async () => {
  let state = $state({ enabled: true })
  let now = Date.now()
  vi.spyOn(Date, 'now').mockImplementation(() => now)

  const client = new QueryClient({
    defaultOptions: {
      queries: { staleTime: 60_000, retry: false },
    },
  })
  client.mount()

  const key = ['items'] as const
  let response: ReturnType<typeof Promise.withResolvers<void>> | undefined
  const reads: Array<{ page: number; signal: AbortSignal }> = []

  const options = () =>
    infiniteQueryOptions({
      queryKey: key,
      enabled: state.enabled,
      initialPageParam: 0,
      queryFn: async ({ pageParam, signal }) => {
        reads.push({ page: pageParam, signal })
        await response?.promise
        return {
          items: [pageParam],
          next: pageParam === 0 ? 1 : undefined,
        }
      },
      getNextPageParam: (page) => page.next,
    })

  // Load two pages, then leave the query unobserved.
  const first = new InfiniteQueryObserver(client, options())
  const stop = first.subscribe(() => {})
  await vi.waitFor(() =>
    expect(first.getCurrentResult().isSuccess).toBe(true),
  )
  await first.fetchNextPage()
  stop()

  // Return to the cached query after it becomes stale.
  now += 60_001
  const dispose = $effect.root(() => {
    const query = createInfiniteQuery(options, () => client)
    $effect(() => {
      void query.data
      void query.isFetchingNextPage
      void query.fetchStatus
    })
  })

  try {
    flushSync()
    await vi.waitFor(() => expect(reads).toHaveLength(4))
    await vi.waitFor(() =>
      expect(client.getQueryState(key)?.fetchStatus).toBe('idle'),
    )
    flushSync()

    now += 60_001
    reads.length = 0
    response = Promise.withResolvers<void>()

    focusManager.setFocused(false)
    focusManager.setFocused(true)
    await vi.waitFor(() => expect(reads).toHaveLength(1))

    // Recompute options without changing enabled or query identity.
    state = { enabled: true }
    flushSync()

    const aborted = reads[0]!.signal.aborted
    response.resolve()

    await vi.waitFor(() =>
      expect(client.getQueryState(key)?.fetchStatus).toBe('idle'),
    )

    expect({
      aborted,
      pages: reads.map(({ page }) => page),
    }).toEqual({
      aborted: false,
      pages: [0, 1],
    })
  } finally {
    response?.resolve()
    dispose()
    client.clear()
    client.unmount()
    vi.restoreAllMocks()
    focusManager.setFocused(true)
  }
})

1. Load two pages of an infinite query whose query function reads the provided signal.
2. Unsubscribe, retaining the cached pages.
3. Let the query become stale, mount it through createInfiniteQuery, and allow its initial refetch to finish.
4. Let it become stale again and trigger a window-focus refetch.
5. While the first page request is pending, replace reactive state read by the options accessor with an equivalent object. Keep the query key and enabled value unchanged.
6. Observe that the pending request is aborted and the first page is requested again.

Expected behavior

The existing refetch should continue without cancellation or duplicate requests when the query identity and enabled state remain unchanged.

Expected: aborted: false, requested pages [0, 1].

Actual: aborted: true, requested pages [0, 0, 1].

How often does this bug happen?

Every time

Screenshots or Videos

No response

Platform

• OS: Windows
• Reproduced using Vitest 4.1.11 with jsdom 30.0.1

Tanstack Query adapter

svelte-query

TanStack Query version

6.1.48

TypeScript version

6.0.3

Additional context

No response