[Bug?]: internal $fetch (Nitro) looping endlessly in build pre-rendering since 1.0.7

[Jylth]

Duplicates

• I have searched the existing issues

Latest version

• I have tested the latest version

Current behavior 😯

Since 1.0.7, in a setup where we have internal API routes, and we're trying to fetch them in the nitro build through the $fetch helper, the page is rendering endlessly in a stuck loop.

https://nitro.unjs.io/guide/fetch#in-server-fetch.

Downgrading @solidjs/start to 1.0.6 fixes the issue.

Expected behavior 🤔

Same behaviour as 1.0.6, which doesn't break internal api calls through the $fetch event helper.

Steps to reproduce 🕹

Steps:

1. Go to https://stackblitz.com/~/github.com/Jylth/solid_issue_prerender_fetch_internal_api?file=src/routes/index.tsx
2. Run a build with pnpm build
3. Observe that the page prerendering of the index is looping endlessly

To fix the issue, simply downgrade the @solidjs/start package to 1.0.6.

Context 🔦

This breaks an app which was working well since a couple of months on v1.0.6. Upgrading to a more recent version of the package breaks it completely.

The behaviour on a more complex app is a bit different. Instead of looping endlessly, the nitro server simply stops after trying prerendering the route and the build fails. Logging the requests in a middleware shows that the internal API calls are received, but the path of the request is missing, they all go to the root /.

Might be the same issue as #1640

[ryansolid]

Oh interesting.. I didn't know $fetch existed. And since Vinxi doesn't use Nitro in Dev I'm a little surprised it ever worked. I have to admit I have no idea what would have changed in 1.0.7 other than updating the Vinxi version. So we might need to track back through those changes.

[Jylth]

Yeah indeed, in our app, the $fetch in development is mocked and replaced by the native fetch via a middleware.

But It does work very well in production, using cloudflare workers.

I was also suspecting vinxi, but forcing the resolution of Vinxi to the same version as the one used in solid-start 1.0.6 ([email protected]) does not fix the issue.

[ryansolid]

Hmm.. it's just that 1.0.7 vs 1.0.6 had very minimal changes on our side. The only thing I can think that could be related is: #1586.

Other than changing to support encoded URLs in the API router nothing else changed Start's build. We did update Vinxi from 0.4.1 to 0.4.3 though.