The most common reason I've seen for this type of function timeout is an expired, missing, or invalid environment variable used for database connection. It could also be related to a breaking change in one of the required packages.

There's a guide with a few more ideas. Can you give these a try and let me know if any of them work for you?

https://vercel.com/guides/what-can-i-do-about-vercel-serverless-functions-timing-out

Thanks for sharing that guide.

I have tried to increase the timeout duration to 30 seconds for my function that was timing out after the base 10s limit. The request still timed out on Vercel and in the logs: [GET] /purchase-orders status=404, and even though the page loads longer on the logs I still see: Execution Duration / Limit: 33ms / 10s , on Netlify: Finish: 2.23 s DOMContentLoaded: 1.09 s Load: 1.19 s, from network inspect tool.

As for the other topics like Function Isn't returning a response or Infinite loop or Upstream Errors the combination of the fact that some pages do load the data correctly would imply that my env variables are correct, and the fact that the pages load on Netlify implies that there are no infinite loops in the code or code that doesn't return a response.

Do you have an idea for what else I could try?

Can you double check the environment variables and upstream service URLs? If one is misconfigured it could cause this kind of problem.

Just to be sure I removed all the ENV and re-added them. The database is Turso and the some pages queries are working so I think that is ok, if that is what you mean by upstream URLs. Comparing the pages that did load data to the ones that didn't, the ones that loaded had much smaller queries. I tried to test this out by increasing the size of query and at a certain point the pages break. I estimate the size of the payloads using Buffer.byteLength(JSON.stringify(data), "utf8"), and it seems that its breaking around at certain sizes, around 11k bytes. I replicated this with another page and query:

1. worked when returning est. 10985 bytes then broke at est. 11296 bytes
2. worked when returning est. 10372 bytes then broke at est. 10440 bytes Is there some type of limit that could be affecting this? The only thing I changed between the tests was the number of rows returned by the DB call.

Interesting. That doesn't seem like it should be a problem, but you can find the function size limits here: https://vercel.com/docs/functions/runtimes#size-limits

vercel.com

Runtimes

Runtimes transform your source code into Functions, which are served by our CDN. Learn about the official runtimes supported by Vercel.

I have a few other ideas:

• Are you able to confirm that the requests reach your Turso database and that valid data is returned? I'm curious to know if it's being delayed by the Turso response or if something else is delaying execution.
• Do you have a try/catch statement around the function to handle errors? It's possible something unexpected is happening, and adding console.log() in a few places could give you more clues about how far the function gets before failing.
• Does your project use a custom URL or a free *.vercel.app subdomain? Some services require configuration of a return URL or allowlist.

I tried the same API call on my local development server and building and running it locally connected to the remote DB and all were able to receive and load the data from Turso, so I don't think it's an issue from their response. I added console logs after each line of the function and the function starts and gets to the call requesting data from Turso after which it dies, now it's receiving a 404, function /_not-found.

To test these changes, I am using the Vercel preview URLs. However, since the calls are working on some pages and for some sizes of requests, I don't think it's the URL as I would imagine that would affect across the entire site for all requests.

Since the function starts and then fails on the Turso request with a 404 status, that indicates a problem with the request path. If your remote DB has logs available then you may be able to find more info about whether the database was reached at all. It could also be a permission issue if the database does not allow the endpoint to be visible with the credentials used. I recommend investigating the DB connection more closely for that specific request.