is there a 50ms limit even with the "Unbound" usage model?

i tried switching to that but still observed issues

Pages always uses Bundled workers, even if you’re on a paid plan and selected Unbound by default. They said they may let you change this later, but for now it can be a real hurdle.

The 50ms limit only affects processing time, not waiting for async stuff

So API calls and stuff don't contribute to that limit

Like I said, it's pretty hard to hit it

If you're on wrangler, I would suggest adding some

console.time()

and `console.timeEnd()`s to check for anything wacky

I've seen some people accidentally do recursive calls to the same script, by calling stuff like

next()

and creating a recursion

Just for future reference, creating a symlink to the functions directory as part of the build step worked! (i.e.,

ln -s path/to/functions ./ && <remaining build steps>

Makes sense... is there a way to configure a safe fallback in case the 50ms limit is reached? I understand that the 50ms limit should be pretty hard to hit but it's a bit scary to think that any failure from the Function will result in the entire site breaking

Iirc there's a setting somewhere if you want to "fail open" or "fail closed", with fail open it just redirect to your origin, and with closed it will dispaly an error page and not let you on the site. I'm not sure how that applies to function, and if it's even an option

generally speaking, you'd want to structure your page asynchronously, ie: serve your index page ASAP, then have some JS on your page query a function (which would contain your long running stuff)

then you can have a js handler handle any exceptions

alternatively, you could have your function call another function (using fetch), then have the first function catch a 1102 or whatever

if you're serving a page, I'd definitely suggest the former though; I'd stay away from running anything w/ time complexity greater than O(N) inside of an interceptor/middleware. Then again, like I said, the 50ms should be really difficult to hit

*to clarify, it's processing only. It takes my browser ~50ms to calculate 10000 digits of pi from scratch, for example

logging into my mongodb cluster can take ~500ms, but the function doesn't consider the "waiting" as part of the function's budget

Ah gotcha -- we're using the function to intercept the request and inject

<meta>

tags for page previews on social sites

this felt like the easiest approach since we're serving a SPA through Cloudflare Pages

So it sounds like this approach could definitely work if we want to be really safe about it

FWIW, we found out the cause of what was taking up the processing time but just want to make sure there's a safe fallback out of abundance of caution

I asked in general as well, not sure which channel is more apropriate (i can delete one as necessary) I have a svelte based pages site, the moment I've added the /functions folder I get an error only at the deployment step: 17:10:37.757 Finished 17:10:38.915 Compiled Worker successfully. 17:10:38.931 Validating asset output directory 17:10:39.416 Deploying your site to Cloudflare's global network... 17:10:49.695 Failed: an internal error occurred Not much to go on. I have no issue running the site and functions locally with wrangler@beta

Hey.. yeah that issue is pretty non-informational indeed. Can you check how big the generated

_worker.js

file is?

how can i see that, I don't really have access to the CI. Not sure how to generate it locally

not sure how that ended up in one of my 2 worker files: import { convertToObject } from "typescript"; // removed this and it worked.. Though I would still like to know how to generate the _worker.js file locally so that I can better debug 🙂

If you run your build command locally that should generate it right?

Oh no.. the Pages integration does that. It will need to generate it when you run

wrangler pages dev

?

With wrangler2?

wrangler pages dev /functions --kv namespace wrangler pages dev --kv namespace --proxy 5000 -- rollup -c -w yeah

so i never see the _worker.js locally