Remove the `export const runtime = "edge"`. It is not needed in use server files
Remove the
export const runtime = "edge"
CIt is needed for any server side code. The issue is with the context which is a sync function and all server actions functions must be async
DNo it's not, the error is clearly highlighting that line. I use server actions too and can confirm that the runtime option is unavailable/not needed. Do ensure that you have it in your root layout or in single pages, tho
DAlso, about the context, you're calling
getRequestContext()
JHeya, can you open an issue on the opennext-cloudflare repo for cron support
JThe problem is that you're exporting the runtime from an action file. Actions don't need that. You only need to export the runtime from either a layout or a page file
MSure 
DHi everyone, my CF builds for next.js just stopped with a message
and nothing has changed in the config, I am not using the not found page it is auto-generated. Has anyone experienced similar?
UPDATE: Just fixed by itself after some time, really strange
and nothing has changed in the config, I am not using the not found page it is auto-generated. Has anyone experienced similar?
UPDATE: Just fixed by itself after some time, really strange
JSounds like a Next.js issue
PI'm aware that the edge runtime builds as required/requested or something like that but I was wondering request times should by in the 6-8s realm?
JSounds odd. Maybe it's network requests inside the app or very large component trees?
PI do have an API it calls that does roughly take 6s but I have a skeleton UI that should display whilst it's doing so. It functions as intended with the skeleton UI when I'm testing locally.
Pnew to next on cloudflare. I just pushed and built my prototype project without adding
export const runtime = "edge"I also just saw in my logs that all pages have been built as edge function routes uncluding those, where I didn't delcare edge runtime at the top. I'm confused 
DYou need to add it only to the layout.tsx file
PNormally if there’s issues with the runtime declarations, it’ll show the files/routes in the build log then fail.
Pthx! I didn't come to a clear conclusion with the current documentation, especially when I reached the point in Trouble Shooting that said one has to make a custom error page with runtime = edge
Pok so I can expect to run into problems immediately . Thanks!
TGetting this error when I try to deploy a static nextjs application
I have output: "export", on next.config.mjs file
I have output: "export", on next.config.mjs file
JIt looks like you're not using next-on-pages so have the wrong output directory or wrong build command set
PIs there a way to access bindings in a client component? I have a hono worker, and I want to use hono's client rpc features inside a client component
HIf you mean a client-side component, then no
KI'm developing a Nextjs application that I basically will needs the seo features because all my backend is hosted on a external api, so sould I host this project on cloudflare pages or workers?
Kthis is a personal project so I would like to stay in free tier, so what shoud I chose ?
MI'm using nextjs with workers on static assets and I'm noticing that even an emptyish project is causing worker CPU usage to spike to several hundred MS
From my standpoint, every page that I'm deploying has "use client" and I'm not doing any API calls. Frankly, everything should be static and so Idk what is even calling workers.
Is there a way to know what endpoint causes the CPU spikes? Or even know what endpoint is considered "static" and what endpoint is actually a worker running
From my standpoint, every page that I'm deploying has "use client" and I'm not doing any API calls. Frankly, everything should be static and so Idk what is even calling workers.
Is there a way to know what endpoint causes the CPU spikes? Or even know what endpoint is considered "static" and what endpoint is actually a worker running
Nif you do
next build
MThanks for the reply. So all my pages are static and the only dynamic API call is never made. The API call is hello world anyways
Any ideas what could be hitting my workers and causing the CPU? IDK why worker requests are even being made in the first place. Tails shows requests as I navigate between the static pages i.e. "/dashboard" and it's not clear why
Any ideas what could be hitting my workers and causing the CPU? IDK why worker requests are even being made in the first place. Tails shows requests as I navigate between the static pages i.e. "/dashboard" and it's not clear why
HJThat's because your requests go through the routing system
MI could do this, but I want to eventually use the nextjs api routes, and so doing that would require me to have two seperate deployments.
MI swear I've read https://developers.cloudflare.com/workers/static-assets/routing/ several times and also thrown it into perplexity to see if it'll help explain my situation but I feel like the actual experience is different from the documentation.
From the documentation, it seems like requests to static pages (i.e. "dashboard" should not be hitting a worker but tails and baselime show that it does). In addition i'm suspecting that for whatever reason that this sometimes causes several hundred ms of CPU usage
From the documentation, it seems like requests to static pages (i.e. "dashboard" should not be hitting a worker but tails and baselime show that it does). In addition i'm suspecting that for whatever reason that this sometimes causes several hundred ms of CPU usage
Cloudflare Docs
How Workers assets' routing and its configuration works.
MThis is a screenshot from the documentation, and from my exerience, visiting "blog" would actually hit a worker. Since this example is seemingly identical to me visiting "dashboard" that is shown to be static on deployment (I'm using nextjs on workers)
JThose are the Workers docs not the Pages docs - next-on-pages is for Pages. The Cloudflare Pages docs has a section for deploying Next.js which touches on this a bit.
https://developers.cloudflare.com/pages/framework-guides/nextjs/ssr/
https://developers.cloudflare.com/pages/framework-guides/nextjs/ssr/
MOkay, so i should ask the question inside of the workers discussion instead. Thanks
JThere's a lot of work going on to re-use parts of the AWS adapter and share the same architecture between the two. This is mostly happening in the experimental branch but also requires a lot of changes in the AWS adaptor to make re-use easier. So there's still things happening, and you can try them out with
https://pkg.pr.new/@opennextjs/cloudflare@experimental
AHey, is it possible to export a Workflow or a Queue handler in a Pages' custom worker entrypoint that's mentioned here? https://developers.cloudflare.com/pages/framework-guides/nextjs/ssr/advanced/
or are only fetch handlers supported i.e. I would either have to create a new worker or migrate to the experimental opennext?
edit: it's not supported got
or are only fetch handlers supported i.e. I would either have to create a new worker or migrate to the experimental opennext?
edit: it's not supported got
Configuration file for Pages projects does not support "workflows"Cloudflare Docs
If you need to run code before or after your Next.js application, create your own Worker entrypoint and forward requests to your Next.js application.
�I was getting the following issue with my website, using edge runtime SSR and nextjs-auth0. It would load for users but it'd emit an error 500 when
GET /error.json3.94KB
�I think the key here is
but doing a Google search didn't get me a lot of good results
but doing a Google search didn't get me a lot of good results
Vhttps://github.com/opennextjs/opennextjs-cloudflare/pull/140 is what we were up to lately...
Right out of the oven, consider it bleeding edge and we will stabilize next.
Right out of the oven, consider it bleeding edge and we will stabilize next.
GitHub
@dario-piotrowicz @james-elicx @petebacondarwin Here is what I have been working on.
/cc @conico974 - I will never thank you enough for all the support!
disclaimers:
it's a preview on an &...
/cc @conico974 - I will never thank you enough for all the support!
disclaimers:
it's a preview on an &...
JThe Cache API for cloudflare pages says it automatically works with Next.js https://developers.cloudflare.com/pages/framework-guides/nextjs/ssr/caching/
My question is what does the "deafult" mean, what is it used for by default, because from what I see by default it does not cache anything, we would need to integrate that cache inside our app logic to make it work?
I am also guessing it does not automatically cache ISR pages since ISR does not really work with edge runtime. https://developers.cloudflare.com/pages/framework-guides/nextjs/ssr/caching/
Anyone has some concrete experience with this?
My question is what does the "deafult" mean, what is it used for by default, because from what I see by default it does not cache anything, we would need to integrate that cache inside our app logic to make it work?
I am also guessing it does not automatically cache ISR pages since ISR does not really work with edge runtime. https://developers.cloudflare.com/pages/framework-guides/nextjs/ssr/caching/
Anyone has some concrete experience with this?
JISR doesn't work with next-on-pages due to Next.js limitations. The cache API is used for the fetch cache by default
VWe have an update for people hitting the 1MiB size limit on free accounts
See https://github.com/cloudflare/workers-sdk/discussions/7030#discussioncomment-11393115
TL;DR We bumped the limit to 3MiB for free accounts
See https://github.com/cloudflare/workers-sdk/discussions/7030#discussioncomment-11393115
TL;DR We bumped the limit to 3MiB for free accounts
Jand fetch cache is not used for Next.js pages directory so what I found is that on pages directory your only option is getServerSideProps and cache through cloudflare domain proxy
JMost of the docs for Next.js https://developers.cloudflare.com/pages/framework-guides/nextjs/ssr/ actually applies to app router more then pages directory, which was not clear to me from the get go.
IGood to know - perhaps it should be added to the Workers Changelog (that way it also goes into No Access automatically)?
CGuys... the last patch/build you released ~3h ago for next-on-pages broke our project... we're getting 500 errors even if we rollback our deployments!
NAs Chinoman mentioned, since the release of
Every time we try to access we get this error on functions
We already tried to use other versions to build the project, but with no success, we get this error instead (using 1.13.5 and 1.13.2)
We'll be appreciated any assistance here, thanks.
@cloudflare/next-on-pages@1.13.6Every time we try to access we get this error on functions
We already tried to use other versions to build the project, but with no success, we get this error instead (using 1.13.5 and 1.13.2)
We'll be appreciated any assistance here, thanks.
J
JAs mentioned on the GitHub issue, please bump your compatibility date so that you are using the newer version of nodejs_compat - Vercel forced every build to have
async_hooksnode: