No I'm connecting to a durable object from a worker and yes I understand how hibernation works.
No I'm connecting to a durable object from a worker and yes I understand how hibernation works.
HNot sure I understand what you mean? DO WebSocket billing is the same whether the originator of the WebSocket is a browser or a Worker
IAnother worker is the client that connects to a durable object that acts as the server. Basically I'm doing pubsub as the official Cloudflare product still isn't open. I'm asking how the billing works on the client side and not the server.
HClient Pricing: One Request per invocation, plus any CPU Time you consume
HBut only while processing. Keeping the WS open shouldn't be billed, though note that after about 30s you aren't guaranteed it won't be evicted
JHello Cloudflare lovers! I just wanted to share a little worker snippet that I'm using to display a book cover given a title and author. It helps me display book covers for over 20k books without having to upload any images! https://gist.github.com/jamesflores/85e9777d5ca076b2d29312a31754003e
Gist
Cloudflare worker that returns a book cover given a book title and author name using the Open Library API - worker.js
N:woe: why
Nits nice to avoid callback hell
Nand to conditionally enter
Nhmm i see the reason for not implementing is just that its complicated and error prone
N¯\_(ツ)_/¯
Ni guess ill have to do that
NI guess I can use this as an alternative to that weird code to make it a bit simpler
AI am uploading a worker using
Are there any issues with source maps uploads right now?
wrangler deploy workers.api.error.unknown [code: 10013]. If I remove upload_source_maps = true from wrangler.toml it starts working correctly. This used to be working before.Are there any issues with source maps uploads right now?
Wcc: @Nevi | Product Manager
AI just checked the above and this is not limited to just one worker, its affecting all of our worker deploys. Same symptom, commenting out the
upload_source_maps makes the upload work.WRaised up to support so they can ping eng
W
AThis error is back again (It was back to working yesterday).
DLet me try and repro
Dcan repro, let me raise
SHello
SHow I can trigger WAF rule based on operation system ?? so if i want to block linux for example how I can trigger that
AShort version - you can't. If you're relying on the User Agent, those can easily be changed. (I'd also generally discourage blocking based on a users OS)
Show I can block based on user OS ??
ZLook one message up, Arch answered you.
DThis should be fixed now
SHi! I'm working on a discord bot that i'm running on workers. The same code executed locally works, but on a worker it gets a CANCELED outcome and I'm struggling to understand why. There's a not of helpful info attached to it, nor am I abel to find any documentation related to it.
What causes the outcome to be CANCELED?
What causes the outcome to be CANCELED?
KHello people, Where to share my open-source project related to workers? 
KAre you using Service Bindings?
K#what-i-built
KYayy thankss
SI have 2 KV bindings.
EDIT: just educated myself - no, not using any service bindings, but making a few API calls to discord in the lifetime of the request
EDIT: just educated myself - no, not using any service bindings, but making a few API calls to discord in the lifetime of the request
SI think I found out why - I added some waits to retry the rate limited calls, and that increases my CPU time way beyond the free limit of 10ms. (Not the ideal way to do it, I know. I'm exploring Workers so this is fun 
)
)
UA wait/setTimeout doesnt use CPU time, what does use CPU time is parsing the data from KV (or from the discord api) so the larger the value the more CPU time it uses. Local dev doesnt have any CPU limits thus it works fine no matter the size
UAnd KV doesnt really have rate limits so I highly doubt the calls to KV are ever being retried but the 1st call will succeed
SMy calls are to a third party api, some manipulation on the data and then create a thread and post multiple messages on that thread. But as you say, IO wait time would be different from CPU time, so I'm back to square one, on why the request gets cancelled before I return a response :/
Walso canceled is not due to cpu limits
Wcanceled means the client cancelled the request
Wso your Worker took too long to respond and the request was cancelled
Wif you're using interactions, they have a pretty fixed time to respond unless you defer
Wwaiting for these apis and things all add to that wall time limit imposed on you
Wi'd recommend deferring and responding when you can
Bcan I not add secrets in
Something like this:
.dev.varswrangler.tomlSomething like this:
K[vars] shouldn't contain secrets.Bwhy?
KBecause that's what secrets are for. They can't be seen in the dashboard and aren't in files that you commit to VCS (like Wrangler.toml)
