No. The browser will decide how long to cache in the case of Browser TTL, and Cloudflare will decide
No. The browser will decide how long to cache in the case of Browser TTL, and Cloudflare will decide how long to cache in the case of Edge TTL
IThe Cloudflare cache is shared among all customers so if there's a lot of traffic from another customer and not much from you then your object might be evicted sooner than the Edge TTL specifies
Yso if my file is not being updated at all, the only thing I can do is to hint the browser and edge TTLs?
Yor is there something more I can do
INot really. Just hint the TTLs for as long as you can, and it should be cached in many cases.
Yalright thanks a ton
Yso how can I handle these 2 folders or all folders and files in the bucket?
Yso there is no way I can make a cache rule that works for everything in the website?
YI'm not using a subdomain
Yjust a custom domain directly
Yyes
Ywill do
Ythanks a lot
Y(http.host eq "domain.name")
DI'm running into a fair amount of these errors:
✘ [ERROR] Error: put: We encountered an internal error. Please try again. (10001)
✘ [ERROR] Error: put: We encountered an internal error. Please try again. (10001)
GMe too. WNAM region. No declared incident. This is a weekly occurence for R2
Dbleh 
Gyou get what you pay for 
Dwhat kind of files are you uploading?
DOddly my bucket that I'm uploading PDFs to doesn't seem to error out, but the one I'm uploading JSON to is erroring out.
GOh, interesting. Yeah, it's happening only with JSON files for me actually
Gmight be a coincidence though
Dthe thing is my PDF files are being uploaded "slower", since I'm tee'ing to create 3 ReadableStreams and uploading them to two R2 buckets, and Azure.
Dso maybe the pressure thingy of a Worker is reducing the odds of an error?
Chowdy all, I have a quick question about large downloads from r2 just failing mid download. It only seems to happen for some users and for those users it happens all the time.
CI guess I'll have to build that functionality out.
CThis caught me off guard tbh, I went months with no issues in our playtest bucket and when we switched over to the prod one (everything is the same except the name), we had issues up wazoo with the exact amount of users.
CHm, how do issues like that look?
CLike is there some documentation of a limit, or it's more of a quirk
CZoinks
CWell, let's see how it all goes then.
CWe're going "live" soon and I guess we'll be scrambling to reply to people to let them know whats up
GTo add insult to injury, if you do uploads from a Worker, you can't even retry a failed R2 write in most cases
GBecause the stream is gone (if it was coming from the user)
Gor you read it into memory and hope you don't hit the poorly-documented 128MB memory limit
GI think we'll be migrating to S3 for our production workloads, this is simply too unreliable. I'm actually having trouble imagining someone running a production service on R2 as it exists today
Gunless you're just happy accepting the unreliability
Gyep
Dwe're tee'ing to two R2 buckets at once, so in theory we can write a cron Worker that syncs the two up later... kinda ugly and is now 2x the storage though.
Dwhat do you mean?
JHey guys, very new to R2. Any recommendations for uploading big files?. Thanks
JCould you point me to some docs to learn about it?
DI personally prefer splitting the file in the application instead of using multipart files.
JThank you
Dis this wnam too?
DSo I managed to delete my 1tb of data from r2... except for a few "Ongoing Multipart Upload" which weirdly appear to be 3.94 GB in size! I can't delete these using the gui and I can't delete them using rclone..... any ideas?
Dno
DI hadnt thought about this, thank you!
Zdoes it say "network error" or "transfer closed"?
Cits happening inside of an "embedded" application and due to me having bad logging i cant say for sure.
Cthis is like
