Unless Remix decides to serve the images for you. You should be able to tell it not to, if it does
Unless Remix decides to serve the images for you. You should be able to tell it not to, if it does
AYeah, just on the page. It's a nice site, but just a site. That's kinda amazing. No fuss, no muss.
- Is CF likely to copy them into its cache? Just trying to sort out my mental model for all this.
- And would GH/Cache serving be terribly slow, i.e., is there a downside I'm not considering?
A(And thanks much for the thoughts.)
HSort of? Files on Github/lab are run through the build process, if there is one, then uploaded to KV. Pages will then, when a request is received, pull the assets from one of the KV origins(EU or NA), cache it in the datacenter it was requested from, and then serve it to the user. Whether the request was cached or not, it will be served at no charge to you, unless the route that was invoked also ran a Function(in this case, via Remix).
AAh. OK.
So I guess there's an intermediate layer in CF which is serving as a kind of cache (KV), even if it isn't some official thing designated as "Cache."
And I suppose this must be part of the overall Pages service you're signing up for when you use it to deliver a site...?
This was very helpful. Thanks. I may get a little confused again between now and final deploy, but I feel better about this now — seems like I have a viable plan.
So I guess there's an intermediate layer in CF which is serving as a kind of cache (KV), even if it isn't some official thing designated as "Cache."
And I suppose this must be part of the overall Pages service you're signing up for when you use it to deliver a site...?
This was very helpful. Thanks. I may get a little confused again between now and final deploy, but I feel better about this now — seems like I have a viable plan.
HNot quite? In this case, KV is the backing store and the cache for Pages
HOnce a deployment is created, it is completely independent of Github. In fact, you should be able to delete the repo entirely, and the Pages Project should continue to work uninterrupted
AOK. That's a good place for me to start. I'll probably circle back as I get closer to finishing.
Really appreciate it.
Really appreciate it.
J
J
JFor orgs it should be:
https://github.com/organizations/{ORG_NAME}/settings/installations/{ID}
Nis there a max request duration for a pages function
Nor like a way to see if a request is timing out
Nin the logs
Nwould a 500 code mean its timing out
Nbecause it makes no sense... i have a log, a fetch, and a log
Ni see the first log
Nnot the second
Nand it returns 500
Nnvm im stupid
Ni missed the error log
Nalso noticed that the logging solution we use (axiom) released an update 8 years ago adding 
cache: 'no-cache' to their requests... no wonder we had no logs from a worker in the past 5 days 
WFree plan: 10ms CPU time
Paid plan: 30 seconds of CPU time
Paid plan: 30 seconds of CPU time
W500 can mean a million things haha, best to look at lots
Nwas wondering about overall time
Nlike could i wait for a db response for 10 minutes lol
WYep
WBut your eyeball may disconnect before then
WCloudflare zones have a general read timeout of 100 seconds
WWhich can be adjusted on ENT
WBut you could stream for hours if you wanted
WYeah we don't have info if its a user or org
WIt's been a bug since the start of pages
Jah ok, could potentially have two links there, one formatted for org and one formatted for the user. That should solve it for now as you should have all that information available to you
OPages is still using pnpm v8.7.1 by default? It feels like it should be on v9 by now
OThis means all deployments will be ignoring lockfiles
WARN Ignoring not compatible lockfile at /opt/buildhome/repo/pnpm-lock.yaml
ZI just noticed that all my DO bindings in Pages are showing like this:
Zanother artifact of the latest release? the namespaces exist, and the bindings appear to be working, but it does make me nervous to push another release... Actually, I just looked around and another app that I have is showing the DO namespaces correctly. One difference between the 2 apps is that the one showing the broken namespace is wrangler.toml-configured, and the one with the working namespace is dashboard configured.
SHi everyone
wanted to know that has anyone deployed ember fastboot server side application in cloudflare?
is it supported in cloudflare?
wanted to know that has anyone deployed ember fastboot server side application in cloudflare?
is it supported in cloudflare?
ZAnyone else seeing their DO’s not showing up in wrangler.toml managed Pages apps?
OI see this too
Wcould someone make a wrangler issue about it?
ZAbout the dashboard issue? Do we normally make wrangler issues about those?
WIt seems to be happening only for wrangler.toml projects
WWhich indicates something in the wrangler behaviour
WIt may be a dash issue or wrangler issue - no idea.
Starting with wrangler is easiest
Starting with wrangler is easiest
Zok i'll file a wrangler issue. it seems like a dash problem though, since the app is working and getting the DO bindings. it looks like a UI issue.
ZGitHub
Which Cloudflare product(s) does this pertain to? Pages, Wrangler core What version(s) of the tool(s) are you using? 3.60.2 [Wrangler] What version of Node are you using? 18.17.1 What operating sys...
