test/nuxt/use-async-data.test.ts (1)

1157-1173: Clarify the expected behaviour with dedupe: 'cancel'.

The test expects promiseFn to be called 4 times with dedupe: 'cancel'. This is correct because each new call cancels the previous request and starts a fresh one. However, this differs from the objective of "deduplication" described in the PR.

The test validates that even though earlier promises are cancelled, they still resolve correctly (by returning the per-key promise) rather than remaining unresolved or returning undefined. Consider adding a comment explaining this behaviour to distinguish it from dedupe: 'defer' (line 362) where the function is called only once.

  it('should correctly return deduped promises', async () => {
    vi.useFakeTimers()
    const promiseFn = vi.fn(() => new Promise(resolve => setTimeout(() => resolve('test'), 100)))

+   // With dedupe: 'cancel', each call cancels the previous one, but all promises
+   // should still resolve by returning the current per-key promise
    const p1 = useAsyncData('sameKey', promiseFn, { dedupe: 'cancel' })

test/fixtures/basic/app/components/AsyncData.vue (1)

11-14: Consider documenting the hardcoded key usage.

The component uses a hardcoded key 'async-data-component' for useAsyncData, meaning all instances of this component share the same async data. Whilst this is intentional for testing deduplication behaviour, it's an anti-pattern in production code.

Consider adding a comment to clarify this is test-specific behaviour:

+// Note: using a shared key across all component instances to test deduplication.
+// In production, use unique keys such as `async-data-${props.id}`.
 const { data } = await useAsyncData('async-data-component', async () => {
   await new Promise(resolve => setTimeout(resolve, 100))
   return `Hello from async data!`
 })

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: Tofandel
Repo: nuxt/nuxt PR: 33192
File: test/nuxt/use-async-data.test.ts:366-373
Timestamp: 2025-09-10T14:42:56.647Z
Learning: In the Nuxt useAsyncData test "should watch params deeply in a non synchronous way", the foo watcher intentionally updates both params.foo and params.locale using locale.value, simulating a scenario where one watcher consolidates multiple reactive values into a shared params object for testing debounced/non-synchronous behavior.

test/nuxt/use-async-data.test.ts (1)

1156-1195: New dedupe synchronisation test looks sound, with minor brittleness concern

The test correctly exercises the dedupe: 'cancel' path with multiple overlapping useAsyncData calls and verifies that all four returned promises resolve only after the final request completes and that they all observe the final value (data.value === 4). This matches the intent of ensuring that deduped executions share the latest resolving promise rather than earlier, now-cancelled ones.

One minor concern is that asserting promiseFn has been called exactly 4 times bakes in a specific internal calling pattern; if the implementation later changes (while preserving the public semantics that all deduped callers resolve together with the final value), this expectation could become brittle. If you do not intend to guarantee the exact number of handler invocations, you might relax this to assert the final data value and the shared resolution timing, and drop or soften the exact call-count assertion.

Otherwise, the timer usage and assertions look consistent with the rest of the suite.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: Tofandel
Repo: nuxt/nuxt PR: 33192
File: test/nuxt/use-async-data.test.ts:366-373
Timestamp: 2025-09-10T14:42:56.647Z
Learning: In the Nuxt useAsyncData test "should watch params deeply in a non synchronous way", the foo watcher intentionally updates both params.foo and params.locale using locale.value, simulating a scenario where one watcher consolidates multiple reactive values into a shared params object for testing debounced/non-synchronous behavior.