Do we need to redeploy workers after changing to standard billing in order for it to switch?
Do we need to redeploy workers after changing to standard billing in order for it to switch?
SIs it normal for HTMLRewriter to output garbled characters?
\
\
SS\
SSNot sure why it behaves like this
SSeems to be wrangler-related
SNote: Fixed by downgrading to wrangler 2.x
CWorkers should auto redeploy when you change the plan
WThanks. Based on the docs and info I found I assumed the same when I changed it a few weeks ago. Though our unbound request count is now at 10 million and standard at 150. So I suspect something might have gone wrong. Guess I'll try a manual redeploy
CIf you have unbound in your wrangler file then you’ll need to change it there as well
WAh yes, that was it. Thanks! Surprisingly it does seem like the standard model is going to be like 50% more expensive than unbound even though the calculator sound it'll be 70% cheaper. Odd
Awhy can't I install wrangler D:
HAre you installing it globally?
K
KWhere's the issue? 
KThat'll be if you put in lon, lat
KIt should be lat, lon
IKeep in mind it's using MaxMind's GeoIP database, so it's entirely possible for it to be inaccurate yes.
UWell I would assume if they give a city the long/lat will always actually be in the city but the actual location it says might not be accurate yeah 
IYeah.
ILike, for example, I use Starlink which is CGNAT. So the IP is Toronto (not where I am, about 2 hours away)
IThe lon/lat is inside Toronto but I'm not in Toronto 
GHi! Is anyone already tried to compare script code in Javascript in a Workers with the same code in WASM to known if there is interest to code it for example in AssemblyScript ( a variant of TypeScript that generate a WebAssembly code ) ?
HIf you are already writing in (Types)Script, then I wouldn't bother rewriting it in AssemblyScript(unless you are doing it as a learning exercise).
GI'm not used to do TypeScript, but as I've just discover this AssemblyScript that directly return the .wasm file, may be this could be a good change for my workers
HYeah, as a way to learn about how WASM works, it can be a great excercise. I just mean that where possible, raw JS may be preferred over WASM, due to performance reasons. With something like
workers-rsThank you for the precision 
BAre there plans for smart placement to support multiple "smart locations"? For example if you have a standard replicated database with 6 locations around the world, workers could hypothetically determine that it should use smart placement in those 6 locations, and not restrict itself to one of them
BToday, smart placement unfortunately feels like a not great compromise between "always completely global" and just back to being "single region"
BEven if it wasn't necessarily completely automated for every possible ingress or whatever, something like "evaluate smart placement per-country" would be a massive improvement
Mhey there, if i were to create a worker that responds with a pretty large image 
, would it be automatically streamed? are there any automatic optimisations cloudflare does?
, would it be automatically streamed? are there any automatic optimisations cloudflare does?
Bas long as you don't buffer the image in memory, then it will be streamed
Bthe key is to avoid reading the
ResponseSo avoid calling all of these basically, except
Response.clone
BIf you do buffer the body in the worker, then the worker will first wait all the time to fetch the image itself and load it into memory, then respond with it, slowing it down.
BOn the client side (e.g in a browser), whether or not the worker buffers it in memory or not shouldn't have any impact, it can still be streamed as normal
Tdoes anyone have advice on how to do typing when using itty-router-openapi? I've been using zod's infer() to create a type but I'd love to have typing for the "data" argument in handle, all the documentation just sets it to "any"
Chi 
I'm encountering some confusing Worker runtime behavior, would love if anyone more seasoned could chime in
basically:
(Why do we care in the first place? We have some monitoring + logpush configured only for errors, and these "false errors" create noise in those systems)
I'm encountering some confusing Worker runtime behavior, would love if anyone more seasoned could chime inbasically:
- We have a WebSocket opened to a Worker (not a DO, just plain worker)
- When the client closes the WebSocket first, the Worker emits a
WebSocket disconnected without sending Close frame. - The Worker emits a
Network connection lost. - This is counted as a "Script Threw Exception" from Cloudflare's dashboard/api/logpush
(Why do we care in the first place? We have some monitoring + logpush configured only for errors, and these "false errors" create noise in those systems)
KThe
exceptionNetwork connection lost
CI guess I'm confused how to prevent
It looks like that PR has been untouched for 3 months-ish, do you know what the status is or should I leave a comment?
Network connection lostIt looks like that PR has been untouched for 3 months-ish, do you know what the status is or should I leave a comment?
NI'm building a ticketing system and need puppeteer for pdf screenshots. Any eta on when @cloudflare/puppeteer will be available to use in workers? Super keen for this since it will mean I can migrate to Cloudflare from vercel, render.com and aws.
.Hey, I’m using my own express server hosted on my vps to handle request for database updating, and then making the requests on my worker to update things in my database (mongodb)
What is a good way to authorise this? To make sure no one can make random PATCH requests for example? Atm, I’m just using an authorisation header with a random string and then checkin that on my express server. Is there a better way?
What is a good way to authorise this? To make sure no one can make random PATCH requests for example? Atm, I’m just using an authorisation header with a random string and then checkin that on my express server. Is there a better way?
.It’s only for something small so it doesn’t matter really but it’s more of a learning thing
HCreate a DNS record for it, then put the Worker on top.
HThen all requests hitting your origin have to pass through your Worker first, where you are free to accept/deny
.So I’d check if it was a patch, and the route was the specific route that would be on my express server?
HThat, or just never pass a request back to your origin unless it is you making a DB request
.And how would I make sure it was my worker
