DO for co-ordination (who is in what channel/room), D1 for accounts/user data/refs to content (images, files, etc), R2 for the actual files/uploads/etc
(This isn't prescriptive, but a real-time chat app is likely to demand all three, plus potentially Queues for things like email sending, crawling embed tags, etc as you expand)
It'd make sense, the dashboard stats (for unique visitors etc) only update once per hour by default it's just bizarre that for some reason it drops instead of just assuming exactly what it was when it last checked
I (maybe?) found a bug within the R2 access token logic. Last evening I've created a R2 access token with 24 hours validity. This morning I was greeted with many 403 Forbidden errors. Looking at the Audit log I've seen that the token was invalidated / has expired at midnight. Maybe this is the expected behavior, but I would expect "Token creation" + 24 hours as the lifetime.
Hi, I replied to your ticket asking for the affected domains and reproduction URLs - once you get back to us with that on the ticket I can take care of escalating to the right teams
@Erisa | Support Engineer I don't have a similar issue today but want to prevent the same thing from happening to us in the future. Do you have any tools to make sure our Buckets will not get flagged for this? We are currently not using R2 for video assets in production but seeing these issues makes me nervous about a switch over.
I'm not sure what to recommend there tbh, the issue is known and involves the automatic abuse detection systems flagging R2 video traffic which needs to be manually overturned. But I don't know of any ways to proactively prevent it from flagging, except for not serving large amounts of video
Not that it would be a perfect solution, but would this be a "one time" action? So if it gets flagged and overturned manually, will it prevent it from happening again?
Maybe we can work a way out to use a worker to alter our HLS manifest files to include url signing params, but this would create huge overhead as both media segments an manifest files are in the same path prefix.
Just to confirm, Connected Domain is generally fine for this use case? I'm still worried about this because it adds things like Cache and these are usually under the Non-HTML limits.
ToS-wise if you're using R2 you're not in a violation of the terms even if you cache it(usual disclaimer applies, I'm not a lawyer). But connecting a domain has been known to flag the automatic detection in some cases even if you use the native Domain Access feature
I'm not sure if the *.r2.dev*.r2.dev URLs can flag this, I don't think I've seen it before but I can't guarantee anything and those don't have caching so they may not be ideal for most cases anyway
Thanks for clarifying. A clear informational page in the docs would be great in the future. Reading the ToS for this kind of use-case is confusing for non-lawyers