query-collection gcTime not set to underlaying query

[fehmer]

• I've validated the bug against the latest version of DB packages

Describe the bug

Hi, I am not sure this is an issue or intended behavior. Setting gcTimeon the queryCollectionOptions does not override the default gcTime on the tanstack/query.

This is my collection definition:

const collection = createCollection(
  queryCollectionOptions({
    queryKey: ["test"],
    staleTime: Infinity,
    gcTime: Infinity,
   queryClient,

Checking tanstack query devtools the query is still using the gcTimefrom the queryClient.

I do get this warning when the query is cleaned up:

[cleanupQueryIfIdle] Invariant violation: refcount=1 but no listeners. Cleaning up to prevent leak. {hashedQueryKey: '["test"]'}

[spokodev]

Trying to ship a fix for this and ran into a counterintuitive baseline. Locally on main, the following test passes without any source change:

```ts
it(`should forward gcTime from queryCollectionOptions to the underlying query`, async () => {
const customQueryClient = new QueryClient({
defaultOptions: { queries: { gcTime: 60000, staleTime: 0 } },
})
const queryKey = [`gcTimeForwardTest`]
const config: QueryCollectionConfig = {
id: `gcTimeForwardTest`,
queryClient: customQueryClient,
queryKey,
queryFn: vi.fn().mockResolvedValue([{ id: `1`, name: `Item 1` }]),
getKey,
startSync: true,
gcTime: Infinity,
}
const collection = createCollection(queryCollectionOptions(config))
await vi.waitFor(() => expect(collection.status).toBe(`ready`))
const query = customQueryClient.getQueryCache().find({ queryKey })
expect((query?.options as any).gcTime).toBe(Infinity) // <-- passes on main
})
```

Reading `packages/query-db-collection/src/query.ts:571-588`, `gcTime` is not in the destructure list, so it flows into `...baseCollectionConfig` and ends up on the returned `CollectionConfig` (the spread at `L1932`). The observer-options block at `L1147-1166` does NOT include `gcTime` next to `staleTime`, yet the cache entry still reports the user-supplied value. There must be a forwarding path I'm missing (probably the Collection itself reads `config.gcTime` and the underlying query observer ends up with it via a route that's not the explicit `observerOptions` spread).

A few clarifying questions for @fehmer to make sure we're fixing the same thing:

1. The body warning `[cleanupQueryIfIdle] Invariant violation: refcount=1 but no listeners. Cleaning up to prevent leak.` — could you share the full Devtools screenshot where it shows the `queryClient` default `gcTime` instead of `Infinity`? Specifically, is it the Query Details panel `gcTime` field, or the Observer panel `gcTime` field? They can differ.
2. Are you using `startSync: true` (which mounts an observer immediately) or the default lazy mode (where the first subscriber attaches later)? My probe used `startSync: true` and the observer's effective `gcTime` did pick up `Infinity`.
3. Is there a `queryClient.setQueryDefaults` call elsewhere in your app that could be clobbering the explicit `gcTime` after collection creation?

Happy to send a targeted PR once we agree on the exact failing path — would just like a repro that's red on `main` so we can ship a clean RED→GREEN fix.

[fehmer]

Hi @spokodev , sorry for the late reply

1. this is the screenshot from the tanstack query devtools

2. adding startSync: true to the queryCollectionOptions does not change the gcTime in devTools and the cleanup is done after the gcTime set on the queryClient

3. I verified I don't have any setQueryDefaults in my code