Dnope. I'm doing:
5 subrequests to R2 through the bindings.
5 subrequests to the Cache API
2 subrequests to Backblaze B2
If I await between the R2 put's and the Cache API put's, the error goes away.
5 subrequests to R2 through the bindings.
5 subrequests to the Cache API
2 subrequests to Backblaze B2
If I await between the R2 put's and the Cache API put's, the error goes away.
HMight be this?
If the system detects that a Worker is deadlocked on open connections — for example, if the Worker has pending connection attempts but has no in-progress reads or writes on the connections that it already has open — then the least-recently-used open connection will be canceled to unblock the Worker.Otherwise, not sure what it could be
If the Worker later attempts to use a canceled connection, an exception will be thrown. These exceptions should rarely occur in practice, though, since it is uncommon for a Worker to open a connection that it does not have an immediate use for.
DI wonder if there's an undocumented limit still for internal subrequests
HI don't think so? Pretty sure I've run 20+ concurrently before
Dwouldn't that be an exception, not a "Too many subrequests"?
H
Dto the cache api?
HI would assume not, but can't be sure just from the dash
HThe Cache API, DOs, KV. 20+ each
HI can try passing it up to see, but otherwise, might be worth a ticket
Dhuh, weird.
Dwith the same ReadableStream source?
Dfor context, what I'm doing, is shoving the same data into five R2 buckets in each region, and also pushing it into the Cache API (so I avoid a Class B completely in even more situations).
HNo, they were different. Just got a response though, so looks like what you were doing(awaiting them halfway through) is what you are supposed to do
Doh, why is that? I thought this would cause buffering and be bad.
Hcache.put doesn't actually return anything, just an empty promise. R2 does return an R2Object, but that doesn't actually include the body. For the two requests to Backblaze, you can call response.body.cancel() to ensure they are closedDI mean buffering of the input 
HWell, they wouldn't be processed entirely in parallel anyway, since it would only be running half of them at once
HSo it would already be buffering it somewhere
Dhm, good point. I guess it'll probably be fine, since I only take in files <100MB
HOtherwise, you can put it to R2, then pull it back out into Cache. Might be convoluted, but
Doh I was just optimizing so I never technically have to pull from R2 
TIs there a way to publish a JSON environment variable via the dashboard? Docs show how to do this in Wrangler but not the dash (https://developers.cloudflare.com/workers/configuration/environment-variables/)
Cloudflare Docs
Attach text strings and JSON values as environment variables to your Worker.
Dstupid question, how does a Queue decide on it's location?
Fin which repo should i raise an issue with
@cloudflare/worker-types? is it workers-sdk or workerd ?
Kworkerd
SHello guys , I am using cloudflare worker to detect vpn , and I am using
Sif (request.cf.botManagement.verifiedBot) {
// Logic for handling verified bots
// You can choose to bypass certain operations or handle them differently
return fetch(request);
}
to detect the good bots (( using bots managment system )) how ever its not working , and its not detecting the bots , there are some traffic which got detected by WAF known bots , how ever its not detected by worker , can you help me please
// Logic for handling verified bots
// You can choose to bypass certain operations or handle them differently
return fetch(request);
}
to detect the good bots (( using bots managment system )) how ever its not working , and its not detecting the bots , there are some traffic which got detected by WAF known bots , how ever its not detected by worker , can you help me please
KYou need to be on an Enterprise plan with the Bot Management add-on to use that
Swhat is the other option , I want to detect the known bots by the worker , known bots can be used even in free plan
WAlso verifiedBot means like a search engine crawler and things. Services we know are good bots
SCorrect, and this is what I want , simply to find a way that can detect the known bots (( or verified bots )) by the worker
WYou mentioned VPN though?
WThat doesn't detect VPNs
WThe property is faked for those without BM, reason being was to not break workers using them before it was properly gated
WIIRC it always returns false for those without
Sforget about VPN
SI just want a way to detect if the traffic was from known bots (( VERIFIED BOTS )) or not , what is the way that I can use via worker to do that
IYou can't, as Walshy has said above - without Bot Management which requires an Enterprise contract that property will always return
falseKYou can use verified bot category
KAll plans get that
KIt's like
req.cf.verifiedBotCategory or somethingWIs that meant to be available to all? :p
Sbut WAF rules can detect the known bots (( verified bots )) even with pro plan i think
Swhy its not working with workers?
Srequest.cf.verifiedBotCategory
you mean this will work with all plans
you mean this will work with all plans
KYes
S
Sas per the documant verifiedbots should work with all plans
I"Only set when using Cloudflare Bot Management" which is Enterprise-only.
