examples/react/nextjs-suspense-streaming/tsconfig.json (1)

4-8: Formatting improvements enhance readability.

The multi-line reformatting of the lib and exclude arrays improves readability without affecting functionality. These changes follow common configuration conventions for better maintainability.

Also applies to: 34-36

docs/framework/react/reference/useQuery.md (1)

46-48: Clarify onSettled argument semantics to match the signature

The new callbacks and their signatures look consistent with the core types, but the onSettled description (“passed either the data or error”) is a bit ambiguous given the (data, error) signature. Consider tightening the copy to spell out that on success data is defined and error is null, and on failure data is undefined and error is set, to avoid confusion and to mirror how useMutation documents its callbacks.

Also applies to: 112-123

docs/framework/solid/reference/useQuery.md (1)

46-48: Keep onSettled docs precise and consistent with React variant

The added callbacks are documented consistently with React, but the onSettled text (“be passed either the data or error”) doesn’t quite match the (data, error) signature. I’d mirror whatever clarification you apply in the React docs here (explicitly noting which param is set on success vs. error) so Solid users get the same, precise contract.

Also applies to: 250-261

packages/vue-query/src/__tests__/useQuery.test.ts (1)

574-601: Strengthen callback assertions for better regression coverage

This test currently only checks that the four callbacks were invoked. Since core tests already verify ordering, it would still be cheap here to assert that the success callbacks received 'fetched' and the error callbacks received an Error instance (and maybe toHaveBeenCalledTimes(1)), which would better protect the wrapper’s wiring without much extra noise.

packages/react-query/src/__tests__/useQuery.test.tsx (2)

6471-6474: Simplify the queryFn in the skipToken test for consistency

The async queryFn here works, but await sleep(10) followed by return Promise.resolve('data') is more complex than needed. For consistency with the rest of this file and prior learnings, consider the more concise pattern:

queryFn: enabled ? () => sleep(10).then(() => 'data') : skipToken

which keeps the timing semantics while using the standard .then style for side‑effect‑free test queryFns.
Based on learnings, …

---

6778-6811: Consider asserting callback arguments in addition to invocations

This test does a good job checking that onSuccess, onError, and onSettled are all called for success and failure paths. To catch more subtle regressions, you might also assert that the success callbacks receive 'fetched' and the failure callbacks receive an Error (and possibly toHaveBeenCalledTimes(1)), similar to the core tests.

packages/query-core/src/__tests__/query.test.tsx (2)

1308-1329: Align test assertions with “correct order” wording in the description

The implementation looks fine, but this test currently verifies that onError and onSettled are each called once with the expected arguments, not that they are called in a particular order. Either add an explicit ordering check (e.g., via mock.invocationCallOrder or by recording a shared log) or relax the test name to avoid implying an order guarantee you’re not actually asserting.

---

1375-1402: Expand success/failure callback test to validate arguments and counts

This test confirms that all four callbacks are invoked, which is useful, but you could cheaply increase its value by asserting that:

• onSuccessMock and onSuccessSettledMock were called exactly once with 'fetched', and
• onFailureMock / onFailureSettledMock were called exactly once with an Error instance.

That would better pin down the contract of the new lifecycle callbacks at the core level.

packages/angular-query-experimental/src/__tests__/inject-query.test.ts (1)

771-801: Consider verifying callback arguments for more robust assertions.

The test verifies that callbacks are invoked but doesn't assert the arguments passed to them. The queryObserver.test.tsx tests in this PR verify arguments like toHaveBeenLastCalledWith('SUCCESS') and toHaveBeenLastCalledWith('SUCCESS', null). Adding similar assertions here would improve test coverage and catch regressions in argument handling.

Additionally, the test title mentions "after a successful fetch" but it tests both success and error cases. Consider rephrasing to "callbacks onSuccess, onError and onSettled should be called after fetch completes" for clarity.

-  test('callbacks `onSuccess`, `onError` and `onSettled` should be called after a successful fetch', async () => {
+  test('callbacks `onSuccess`, `onError` and `onSettled` should be called after fetch completes', async () => {
     const onSuccessMock = vi.fn()
     const onFailureMock = vi.fn()
     const onSuccessSettledMock = vi.fn()
     const onFailureSettledMock = vi.fn()

-
     TestBed.runInInjectionContext(() => {
       injectQuery(() => ({
         queryKey: ['expected-success'],
         queryFn: () => 'fetched',
         onSuccess: (data) => onSuccessMock(data),
         onSettled: (data, _) => onSuccessSettledMock(data),
-      }));
+      }))

       injectQuery(() => ({
         queryKey: ['expected-failure'],
         queryFn: () => Promise.reject(new Error('error')),
         onError: (error) => onFailureMock(error),
         onSettled: (_, error) => onFailureSettledMock(error),
         retry: false,
-      }));
+      }))
     })

     await vi.advanceTimersByTimeAsync(10)

-    expect(onSuccessMock).toHaveBeenCalled()
-    expect(onSuccessSettledMock).toHaveBeenCalled()
-    expect(onFailureMock).toHaveBeenCalled()
-    expect(onFailureSettledMock).toHaveBeenCalled()
+    expect(onSuccessMock).toHaveBeenCalledWith('fetched')
+    expect(onSuccessSettledMock).toHaveBeenCalledWith('fetched')
+    expect(onFailureMock).toHaveBeenCalledWith(expect.any(Error))
+    expect(onFailureSettledMock).toHaveBeenCalledWith(expect.any(Error))
   })

packages/svelte-query/tests/createQuery.svelte.test.ts (1)

1921-1957: Consider adding argument assertions for consistency with other tests in this PR.

Similar to the Angular test, this test verifies callbacks are invoked but doesn't assert the arguments. The queryObserver.test.tsx tests verify specific arguments. Consider adding assertions like:

       await sleep(10)

-      expect(onSuccessMock).toHaveBeenCalled()
-      expect(onSuccessSettledMock).toHaveBeenCalled()
-      expect(onFailureMock).toHaveBeenCalled()
-      expect(onFailureSettledMock).toHaveBeenCalled()
+      expect(onSuccessMock).toHaveBeenCalledWith('fetched')
+      expect(onSuccessSettledMock).toHaveBeenCalledWith('fetched')
+      expect(onFailureMock).toHaveBeenCalledWith(expect.any(Error))
+      expect(onFailureSettledMock).toHaveBeenCalledWith(expect.any(Error))

packages/solid-query/src/__tests__/useQuery.test.tsx (1)

6171-6208: Strengthen lifecycle callback assertions

The test currently only checks that the four callbacks were invoked. To better lock in behavior, consider also asserting the arguments:

• onSuccessMock / success onSettled receive 'fetched'.
• onFailureMock / failure onSettled receive an Error('error').

This will catch regressions where callbacks fire with wrong payloads or at the wrong time.

packages/query-core/src/queryObserver.ts (3)

153-163: enabled runtime guard is safe but resolveEnabled call is redundant

The guard correctly rejects non‑boolean/non‑function enabled values at runtime. However, because the condition only executes when enabled is neither boolean nor function, resolveEnabled will always just echo the invalid value and the typeof … !== 'boolean' check will always be true. You can simplify this to a direct type check on this.options.enabled without calling resolveEnabled, which also avoids relying on this.#currentQuery before #updateQuery has run.

---

199-217: Avoid repeated resolveEnabled / resolveStaleTime calls in setOptions

setOptions currently recomputes resolveEnabled (and resolveStaleTime) multiple times with the same arguments when deciding whether to update timers. This is correct but means running user‑provided enabled/staleTime functions more than necessary.

You could cache the resolved values for this.options and prevOptions into locals and reuse them in the conditionals to reduce repeated work and make the logic easier to follow, while keeping behavior identical.

---

505-509: Tighten typing for placeholderData callback and previousQuery

The new call passes both previous data and previousQuery into placeholderData, which is great, but the cast via unknown as PlaceholderDataFunction<TQueryData> and this.#lastQueryWithDefinedData as any loses type information.

You can likely reduce any usage and improve safety by casting to the full generic:

const placeholderFn =
  options.placeholderData as PlaceholderDataFunction<
    TQueryFnData,
    TError,
    TQueryData,
    TQueryKey
  >

placeholderData = placeholderFn(
  this.#lastQueryWithDefinedData?.state.data,
  this.#lastQueryWithDefinedData,
)

This keeps the runtime behavior the same while preserving the actual query generics.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: sukvvon
Repo: TanStack/query PR: 9892
File: packages/solid-query-persist-client/src/__tests__/PersistQueryClientProvider.test.tsx:331-335
Timestamp: 2025-11-22T09:06:05.219Z
Learning: In TanStack/query test files, when a queryFn contains side effects (e.g., setting flags for test verification), prefer async/await syntax for clarity; when there are no side effects, prefer the .then() pattern for conciseness.

Learnt from: sukvvon
Repo: TanStack/query PR: 9892
File: packages/solid-query-persist-client/src/__tests__/PersistQueryClientProvider.test.tsx:331-335
Timestamp: 2025-11-22T09:06:05.219Z
Learning: In TanStack/query test files, when a queryFn contains side effects (e.g., setting flags for test verification), prefer async/await syntax for clarity; when there are no side effects, prefer the .then() pattern for conciseness.

Learnt from: DogPawHat
Repo: TanStack/query PR: 9835
File: packages/query-core/src/__tests__/queryClient.test-d.tsx:242-256
Timestamp: 2025-11-02T22:52:33.071Z
Learning: In the TanStack Query codebase, the new `query` and `infiniteQuery` methods support the `select` option for data transformation, while the legacy `fetchQuery` and `fetchInfiniteQuery` methods do not support `select` and should reject it at the type level.