Maintain request context on serverside fetch requests
I have a endpoint in nitro that i need to call other internal endpoints. I need the event.context of the initial request to be maintained/passed to all subsequent internal requests. I have tried event.$fetch, but i get errors when running tests (vitest) saying $fetch is not a function. I tried fetchWithEvent, and it throws a URL parse error with internal (relative) endpoint urls, so i assume that it wants a full url which would suggest thats its not going to skip the http overhead and call the endpoint function directly?? I also tried the useEvent with asyncContext to avoid passing the event context directly, but nitro-test-utils does not support asyncContext. Am I missing something, is there a way to get this working / testing correctly?
2 Replies
Hi @Danny. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
To maintain the request context (including headers, cookies, and event context) when making internal server-side fetch requests in Nuxt/Nitro, you should use either event.$fetch or useRequestFetch. Here’s how they work and what to watch out for:
1. Using
Forwarding Context & Headers 2. Using
useRequestFetch 3. Testing Caveats - In your tests (e.g., with Vitest or nuxt/test-utils), you may encounter issues where event.$fetch is not available or not a function. This is likely because the test environment does not fully mock or provide the Nitro event context as in production. - The knowledge sources do not provide a direct solution for this limitation in the test environment. If event.$fetch is unavailable in tests, you may need to mock it or adjust your test setup to provide a compatible context. There is no official workaround documented for this scenario. 4. About
Experimental async context PR --- Summary:
For production, use event.$fetch in server routes or useRequestFetch in composables/components to maintain request context for internal server-side fetches. For testing, the knowledge sources do not provide a complete solution if event.$fetch is unavailable—this is a known limitation. There is no official workaround for asyncContext in tests at this time. If you need to test this behavior, you may need to mock event.$fetch or adjust your test environment, but this is outside the scope of the official documentation. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
event.$fetch
in Server Routes
- event.$fetch
is designed to forward the request context and headers when making internal fetch requests from within server routes or API handlers. This ensures that the context of the original request is preserved in sub-requests.
- Example usage:
Headers that are not meant to be forwarded (like host
, connection
, etc.) are automatically excluded.Forwarding Context & Headers 2. Using
useRequestFetch
in Composables or Components
- useRequestFetch
is a composable that provides a fetch function which automatically forwards the request context and headers during SSR. It is especially useful when you need to make server-side requests from within composables or Vue components.
- Example usage:
On the server, this will forward the context; on the client, it behaves like a normal fetch.useRequestFetch 3. Testing Caveats - In your tests (e.g., with Vitest or nuxt/test-utils), you may encounter issues where event.$fetch is not available or not a function. This is likely because the test environment does not fully mock or provide the Nitro event context as in production. - The knowledge sources do not provide a direct solution for this limitation in the test environment. If event.$fetch is unavailable in tests, you may need to mock it or adjust your test setup to provide a compatible context. There is no official workaround documented for this scenario. 4. About
fetchWithEvent
and Full URLs
- If a fetch utility requires a full URL and does not support relative URLs, it will not perform an internal function call and will instead make an actual HTTP request, which is less efficient and does not preserve the internal context as event.$fetch does.
- The knowledge sources do not mention a built-in fetchWithEvent utility, so its behavior cannot be confirmed.
5. About Async Context
- There is experimental support for native async context in Nuxt/Nitro, but it is not yet fully supported in all environments (including test utilities), and you noted that nitro-test-utils does not support asyncContext. This matches the current state of the feature as described in the sources, and there is no documented workaround for this in tests yet.Experimental async context PR --- Summary:
For production, use event.$fetch in server routes or useRequestFetch in composables/components to maintain request context for internal server-side fetches. For testing, the knowledge sources do not provide a complete solution if event.$fetch is unavailable—this is a known limitation. There is no official workaround for asyncContext in tests at this time. If you need to test this behavior, you may need to mock event.$fetch or adjust your test environment, but this is outside the scope of the official documentation. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
<@1085582253444304916> Kapa.ai is still learning and improving, please let me know how I did by reacting below.