Nuxt•2w ago

useFetch reactive triggering twice

I'm using vueuse useRouteQuery to get page and limit values from the query params. For the first page, those params don't exist so I have defaults setup. I'm then passing those to the useFetch query object. So the problem occurs when I'm on the first page and go to another page, I get 2 network fetchs to the api, the first one gets cancelled and the second one succeeds but the useFetch gives me the following error:

<no response> Request aborted as another request to the same endpoint was initiated.Caused by: AbortError: Request aborted as another request to the same endpoint was initiated.

<no response> Request aborted as another request to the same endpoint was initiated.Caused by: AbortError: Request aborted as another request to the same endpoint was initiated.

If I'm on a page other than the first where the params are in the query and go to any other page (even the first page) it works perfectly.

8 Replies

kapa.ai•2w ago

Hi @bnason. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- The behavior you're seeing—two network requests when changing the page, with the first being aborted and the second succeeding—is expected when using Nuxt's useFetch with reactive query parameters. This happens because useFetch, by default, deduplicates concurrent requests to the same endpoint using the dedupe: 'cancel' strategy. When a reactive value (like your page or limit) changes, useFetch triggers a new fetch, and if another fetch is already in progress for the same key, the previous one is aborted, resulting in the "Request aborted as another request to the same endpoint was initiated" error message. From the documentation:

There is NO cache by default, dedupe is only useful when making a request multiple times at the same time, subsequent request at later time still send to server, but the result will affect everywhere that use the same request.
Github Issue: UseFetch / UseAsyncData Dedupe not Working

And from the API docs:

| dedupe | 'cancel' | 'defer' | 'cancel' | Avoid fetching same key more than once at a time. |
Nuxt useFetch Parameters

So, when your query parameters change rapidly (such as when navigating between pages and the reactive values update), useFetch may trigger two fetches: the first is started, then immediately aborted when the second is triggered with the new parameters. How to address this: - This is not an error in your code, but expected behavior with dedupe: 'cancel' (the default). - If you want to avoid seeing the abort error, you can catch and ignore AbortError in your error handling. - If you want to change the deduplication behavior, you can try dedupe: 'defer', but this may not change the fundamental behavior if the parameters change rapidly. - Ensure that your query parameters are not being set twice in quick succession (for example, by both a default and a reactive update). Summary:
The double fetch and abort error are a result of how useFetch handles rapid changes to reactive parameters with deduplication. It's not harmful, but if you want to suppress the error, handle AbortError in your error logic, or review your parameter update flow to avoid double updates. If you need more fine-grained control, you can use the immediate: false option and manually trigger fetches with execute, as described in the docs for advanced scenarios Key Change Behavior in useAsyncData and useFetch. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------

kapa.ai•2w ago

<@712351223482810390> Kapa.ai is still learning and improving, please let me know how I did by reacting below.

bnasonOP•2w ago

@kapa.ai 1) There is no rapid change in the query parameter. This is just a single page change after the original page has finished loadaing 2) I have dedupe set to defer already I've verified that there is no rapid change of the query parameters by logging the changes using a watch call. When navigating to a page with new query params, they are logged to the console only once.

kapa.ai•2w ago

Let me check the knowledge base for you again. One moment! :books: ---------------------- Thank you for clarifying the situation. Based on your description and the knowledge sources, here’s what can be concluded: - useFetch triggers two requests (one aborted) on a single query param change, even with dedupe: 'defer'. - You have verified that the query parameter changes only once per navigation. What the Documentation Says - The dedupe option ('cancel' or 'defer') only affects concurrent requests with the same key. 'defer' will wait for the first request to finish before starting a new one, while 'cancel' aborts the previous request if a new one is triggered. However, the documentation and related issues indicate that dedupe is only useful for concurrent (simultaneous) requests, not for sequential ones. There is no persistent cache by default, so subsequent requests (even with the same key) will still hit the server if triggered at a later time Github Issue: UseFetch / UseAsyncData Dedupe not Working. - The useFetch composable generates a key based on the URL and options. If the key changes (for example, due to a change in query parameters), Nuxt will refetch the data. If you use a reactive source for the URL or query, it will automatically refetch when those change Nuxt useFetch: Reactive Keys and Shared State. - There was a recent change to make useFetch and useAsyncData behave consistently: with immediate: false, data is only fetched when the key changes if it has already been fetched once, and you must call execute manually the first time Key Change Behavior in useAsyncData and useFetch. What Might Be Happening Given that you see two requests (one aborted) on a single navigation, and dedupe is set to 'defer', this could be due to how Nuxt internally manages the fetch lifecycle when query parameters are missing (defaulted) and then set (populated) during navigation. Sometimes, the initial render uses default values, and then a second fetch is triggered when the actual query params are resolved, even if the change is not visible in your watcher. This behavior has been observed in community discussions, and is sometimes related to how Nuxt resolves route params and query params during navigation and hydration. The documentation does not provide a direct solution for this specific scenario, but it does confirm that dedupe only affects concurrent requests, and that key changes (even if not rapid) will trigger new fetches. Recommendations - Double-check that the computed key for useFetch is not changing unexpectedly due to how defaults and actual query params are resolved. - If possible, log the computed key or the full options object passed to useFetch before each call to see if there is any subtle difference between the two requests. - If you want to avoid the abort error, you may need to handle it in your error logic, as this is a known and sometimes unavoidable behavior with the current Nuxt fetch lifecycle. In summary:
The knowledge sources confirm that dedupe only affects concurrent requests, and that key changes (even if not rapid) will trigger new fetches. The double fetch with one abort is a known behavior in some navigation scenarios, especially when defaults and actual query params are involved. There is no explicit solution in the documentation for this exact case, but handling the abort error gracefully is recommended Nuxt useFetch Parameters Github Issue: UseFetch / UseAsyncData Dedupe not Working. If you need more control, consider using immediate: false and manually triggering fetches with execute after ensuring the query params are fully resolved Key Change Behavior in useAsyncData and useFetch. If you need further troubleshooting, providing a minimal reproduction may help identify if this is a framework quirk or something specific to your setup. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------

kapa.ai•2w ago

<@712351223482810390> Kapa.ai is still learning and improving, please let me know how I did by reacting below.

bnasonOP•2w ago

@kapa.ai I set immediate false and I'm then manually calling execute ONCE when the params change and its STILL attempting to fetch twice where the first one gets cancelled

kapa.ai•2w ago

Let me check the knowledge base for you again. One moment! :books: ---------------------- Based on the knowledge sources, if you set immediate: false and manually call execute when your params change, Nuxt should only fetch once per change. The upgrade guide explicitly states:

If you have set immediate: false, then you must call refresh or execute or data will never be fetched in useFetch or useAsyncData... If you were expecting changing the key or options of a non-immediate useFetch, you now will need to trigger it manually the first time.

The guide also provides an example where you watch a param and call execute once per change:

const id = ref('123')
const { data, execute } = await useFetch('/api/test', {
  query: { id },
  immediate: false
})
watch(id, () => execute(), { once: true })

const id = ref('123')
const { data, execute } = await useFetch('/api/test', {
  query: { id },
  immediate: false
})
watch(id, () => execute(), { once: true })

Key Change Behavior in useAsyncData and useFetch If you are still seeing two fetches (with the first being cancelled) even when you only call execute once, the knowledge sources do not provide an explicit explanation or solution for this behavior. The documentation and upgrade guide suggest that with immediate: false and manual execute, only a single fetch should occur per change. Summary:
I'm sorry, but the knowledge sources do not contain enough information to explain why you are seeing two fetches (with one cancelled) when using immediate: false and calling execute only once. This may be a framework quirk or an edge case not covered in the official documentation. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------

kapa.ai•2w ago

<@712351223482810390> Kapa.ai is still learning and improving, please let me know how I did by reacting below.

Gaming

Programming

useFetch reactive triggering twice

Did you find this page helpful?