Should useAsyncData be awaited within the setup function? #34332

Sorry for the confusion before. Now I've noticed that although the refresh is working properly, there is still an issue when switching routes. 😭

In current Nuxt 4, both forms are valid. The important distinction is client-side navigation, not SSR.

Nuxt now documents the behavior explicitly:

• During server rendering, Nuxt waits for useAsyncData even when you do not write await, so the resolved result is still serialized into the payload.
• With await, the rest of setup and client-side navigation wait for the data.
• Without await, navigation continues immediately and data is initially its default/undefined value; the component must render its pending and error states.

Reference: https://nuxt.com/docs/4.x/api/composables/use-async-data#usage

That means removing await can make navigation appear to work differently, but it should not be the fix for stale data. Looking at the linked commit, more than await changed: the explicit keys were removed, and the code watches the complete route object. The route object is a stable reactive proxy, while its fields change, so watching the specific value is clearer and avoids reusing ambiguous keyed state.

For a dynamic content page, make the key itself reactive:

<script setup lang="ts">
const route = useRoute()
const contentPath = computed(() => route.path)

const { data, status, error } = await useAsyncData(
  () => `tools-item:${contentPath.value}`,
  () => queryCollection("tools")
    .path(contentPath.value)
    .first(),
)
</script>

Nuxt automatically reruns the handler when a reactive key changes, so no separate watch is needed. The official reactive-key example uses the same pattern:
https://nuxt.com/docs/4.x/api/composables/use-async-data#reactive-keys

For the menu/layout, derive the part that actually controls the query:

const section = computed(() =>
  route.path.split("/").slice(0, 3).join("/")
)

const { data: items } = await useAsyncData(
  () => `tools-menu:${section.value}`,
  () => queryCollectionNavigation("tools")
    .where("path", "LIKE", `${section.value}%`)
    .then(items => items[0]?.children?.[0]?.children ?? []),
)

If you intentionally want one stable key instead, watch a getter/ref rather than the entire route proxy:

watch: [() => route.path]

A few related details matter here:

1. Calls with the same key share data, error, status, and pending. A constant key such as tools-item represents one shared async-data slot, not one slot per route.
2. The handler should return a truthy value. For list/navigation queries, normalize “no result” to []; for a missing content page, throw a 404 rather than silently returning undefined. Nuxt warns that a nullish handler result can cause a duplicate client fetch.
3. If you choose the non-awaited form, display status === "pending" and error; otherwise route changes can briefly render the previous or empty state and look broken.
4. An extra async () => return await ... wrapper is unnecessary unless you need try/catch; returning the query promise directly is sufficient.

So the direct answer is: no, useAsyncData does not have to be awaited. Use await when you want navigation to wait for the result; omit it for non-blocking navigation with explicit loading UI. Fix route-dependent refreshes independently with a reactive, unique key (or a precise watch source).

If this fixes both refresh and route switching in the reproduction, you can mark it as the accepted answer so the await and reactive-key behaviors are easy to find together.