Nuxt•10h ago

random no response errors on usefetch.

hello i have people reporting some issues with problems submitting a form in my project (using useFetch but named differently). the error that happens in the try catch is <no response> Failed to fetch but the connection is OK and server is online. as the error logging also goes in a usefetch post and arrives to the backend fine? when people open a new window in their browser the issue is no longer there. so its very random. how could i diagnose this as i cannot reproduce it on my system? it also is not as descriptive as i would like making diagnosing the issue way harder. anyone with any advice on fixing such issues? it happens on the following post request:

  
    await useApiFetch("/sanctum/csrf-cookie");
    const response = await useApiFetch("/api/competition/signup", {
      method: "POST",
      body: formData,
      headers: {
        Accept: "application/json",
      },
    });

    if (response.error.value) {
      throw new Error("Failed to submit competition, error: " + response.error.value);
    }

  
    await useApiFetch("/sanctum/csrf-cookie");
    const response = await useApiFetch("/api/competition/signup", {
      method: "POST",
      body: formData,
      headers: {
        Accept: "application/json",
      },
    });

    if (response.error.value) {
      throw new Error("Failed to submit competition, error: " + response.error.value);
    }

i have also disabled csrf checking for now to diagnose. but issue still appears..

2 Replies

kapa.ai•10h ago

Hi @sniperfull.. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- Diagnosing random <no response> Failed to fetch errors with useFetch (or a custom wrapper like useApiFetch) in Nuxt can be tricky, especially when the backend is online and the issue is not consistently reproducible. Based on the knowledge sources, here are some points and troubleshooting steps you can consider: 1. Request Abortion Due to Duplicate Calls
There is a known behavior in Nuxt where if multiple requests to the same endpoint are triggered in quick succession (for example, due to reactive parameters or navigation), the previous request may be aborted, resulting in a <no response> error. This can happen especially when using useFetch inside composables or with reactive data. The error can be mitigated by providing a static key to useFetch to prevent unintended aborts:

   const { data, error } = useFetch('/api/competition/signup', { key: '/api/competition/signup', ...options })

   const { data, error } = useFetch('/api/competition/signup', { key: '/api/competition/signup', ...options })

This ensures that requests are not aborted due to key changes or reactivity issues. See the discussion and workaround here: Nuxt issue #31896. 2. Misuse of useFetch in Composables
If you are wrapping useFetch in a custom composable and awaiting it inside the composable, this can cause unexpected behavior. The recommended pattern is to call useFetch directly in the setup function or, if wrapped, not to await it inside the composable. Awaiting useFetch inside a composable can lead to issues with reactivity and SSR/client hydration, which might manifest as random errors. See the advice here: Nuxt docs on custom useFetch and YouTube: You are using useFetch WRONG!. 3. Network/Browser Issues
Since the error disappears when users open a new browser window, it could be related to browser state, cache, or cookies. Consider checking for: - Stale or invalid CSRF tokens (since you call /sanctum/csrf-cookie before the POST). - Browser extensions or privacy settings interfering with requests. - Service worker or PWA caching issues. 4. Error Handling and Logging
The error message <no response> Failed to fetch is generic. To get more descriptive errors, you can enhance your error handling by logging the full error object, including any response status or message, not just error.value. Also, check if the error is being thrown due to a request being aborted (which can be detected by checking for an AbortError). 5. SSR vs. Client-Side Execution
Ensure that your useFetch (or useApiFetch) calls are not being executed both on the server and client unintentionally, which can sometimes cause duplicate requests or unexpected aborts, especially if the composable is not used as intended. Summary:
- Use a static key in useFetch to avoid duplicate request aborts. - Do not await useFetch inside a custom composable; call it directly in setup or follow the official recipe. - Enhance error logging for more details. - Check for browser-specific issues, especially with cookies or CSRF. - Review your composable usage pattern for SSR/client-side differences. If after these steps the issue persists, try to reproduce the problem in a minimal public repo or StackBlitz and share it for further community debugging, as suggested in several Nuxt issue threads. References:
- Nuxt issue: Request aborted as another request to the same endpoint was initiated - Nuxt docs: Custom useFetch - You are using useFetch WRONG! (YouTube) ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------

kapa.ai•10h ago

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

Gaming

Programming

random no response errors on usefetch.

Did you find this page helpful?