I actually don't think that status is related to getting 10001 errors from R2. R2 is still functiona
I actually don't think that status is related to getting 10001 errors from R2. R2 is still functional for me
Eits a developing situation
Further detail will be provided as more information becomes available.
Emay or may not even be related to your issues
Ethere is not, the way you described is the only way
Ewelcome to S3
Ealways a good bet
UHow often do you get 10001 errors and if you retry does it eventually work? And you say on a new bucket... do you have an older bucket that operations work fine on? @RandomNick
Eunfortunately not
Ethat one you can
Rabout 10 each time the bucket page loads
Rno p
Rthe url part of it seems to have a problem...
UAh ok if you are talking about the dashboard... yeah the dashboard has some issues. But actually running using the S3 api or the workers binding api should be fine still.
USeems the dashboard is loading fine for me atm but was having issues a few minutes ago
R
I am trying to setup a public bucket, I guess I'll need the dashboardUThat you do 
SMy approach to this was to just wrap the bucket and store sizes / meta data in a DB
SAh
UThe public access via custom domains / r2.dev only give read access (and only to specific objects no listing).
UIt's also an all or nothing either all objects are public read or none of them are. So you can have 1 public bucket and 1 private bucket.
ENote that custom domains are recommended for anything production, the r2.dev is only recommended for development or testing, does not have caching and has a rate limit in place
ENice
UAfaik its not possible to lie about the content-length or at the very least i'd assume cloudflare would validate it
SCouldn't you write a custom worker to handle the upload and read the content size as you're commiting it to R2?
SI would pick slow uploads over ever trusting the client
SThere shouldn't really be circumstances where the client is providing you with any level of truth (imo obviously)
UI would just make the client send the content length of the file they want to upload and increase in the db their usage by that length and send a signed url that specifies the content length provided so that we can ensure the file is that size.
EThat is not currently a feature
UYes it is
EYeah im pretty sure you can sign the content-length in a presigned url
Eso like, the client determines the length of the file, asks your worker "can i upload this size", the worker decides its okay and returns a signed url that only accepts that length
UI'd assume theres not any docs for most things on R2 directly and instead they hot link out to S3 docs to learn more because they follow the S3 api.
Eif you route all your ops through workers you can try and track usage in a db based on those values
Ebut will have to account for presigned uploads that arent actually completed
Eanother solution is bucket per user but then you run into the max buckets (1k i think) and have to keep requesting a raise
UThis is what I would do
UI would use a DO alarm rather than a cron trigger personally. You can basically create a DO per user that tracks their uploads and you can run an alarm on a per user basis when their next upload link would have expired and check if it was actually uploaded or not.
Eassociate timestamps and dont try to clean up something that was recent enough that the presigned url hasnt expired yet
Eand yeah +1 about alarms
UYeah its KV but better (imo) 
EKV but different
UKV is more of a cache store and DO is more of like a database
EDOs are useful because they can run custom code, its basically a process running somewhere that has its own storage
Eas opposed to KV which is just a flat key/value store, R2 which is also a key/value store but scales higher/with bigger data, and D1 which is just a database
UI'd assume for "scales higher" on R2 you just means larger objects
Eyeah im struggling to word that rn
U
yeah it be like thatUMy personal path way of choosing is pretty much can I use a DO for this? Use a DO. Am I fine with higher cost / do I need/want faster responses and objects arent super large (over 25MiB)? Use KV. Else: Use R2.
UKV is very expensive comparative to R2.
UKV:
- $0.50/million get
- $5.00/million write/delete/list
- $0.50/GB-month
- $0.36/million get
- $4.50/million write/list
- $0.00/infinite deletes
- $0.015/GB-month
Uexpirations on KV do not count as a delete op
