nice, but i would rather them invest in fixing what's broken

except i needed that exact functionality 😄

until you find it's broken too 😉

theres been a few misses, indeed

tho slightly related to this, is there a way to force a worker to only execute in a certain area/region/country?

hi, it's seems if client close web socket and worker always throw the below error,

text
workerd/server/server.c++:2347: error: Uncaught exception: workerd/io/io-context.c++:1261: failed: remote.jsg.Error: The script will never generate a response.
stack: 0 0 0 0 7ff71a146272 0 7ff71a146234 0 0 0
workerd/server/server.c++:2259: error: exception = kj/compat/http.c++:2061: failed: expected !inBody; previous HTTP message body incomplete; can't write more messages
stack: 7ff71a138a6f 7ff71a1d035d 7ff71a205121 7ff71a194056 7ff71a1941fb 7ff719fb2e64 7ff71a1b28ca 0 0
An event handler returned a promise that will be ignored. Event handlers should not have a return value and should not be async functions.                                                                                        
X [ERROR] Uncaught (in response) Error: The script will never generate a response.

So all this does is set my secrets? https://developers.cloudflare.com/workers/learning/integrations/databases/#supabase cc @User (you mind like this too?)

https://blog.cloudflare.com/workers-tcp-socket-api-connect-databases/ I’m curious with the socket api, what happens if you store a global variable with a client/connection? I understand workers get evicted, but assuming the worker isn’t evicted for subsequent requests, would the TCP connection stay available? Or does cloudflare reset external io for every request?

just can't https://developers.cloudflare.com/workers/runtime-apis/tcp-sockets/ "TCP sockets must be created within the fetch() handler of a Worker. TCP sockets cannot be created in global scope and shared across requests."

no DO sockets 😛

i just tested the pg connection using this new stuff. it works.

I think "within the fetch handler" may not be true (ex, you should be able to use other handlers like scheduler/cron), but the rest about not being able to share it is

now to figure out how to use cloudflared to expose a postgresdb only to my workers 😄

I believe DOs are the exception here - you can store it on

this.state

and reuse it fine

Smart placement per route would be amazing (and is necessary for us to enable it because it would not make sense otherwise)

100% agree with @sathoro. This is the one feature that would be very game changing for us. It would also be nice if we can do placements based on HTTP method and custom headers, but I understand that we probably have an unusual use-case and it won't be a priority.

Yeah its something I brought up too but doesnt seem likely from what I have heard

Best bet to achieve it is probably using many workers with worker routes instead of a single worker and the custom domain. Which can be pretty complicated of course 😅

my current workaround to ack being undefined on queue messages:

if (message.ack !== undefined) message.ack(); //because cloudflare...

you can also do

message.ack?.()

I learned this disgusting code from @Skye

You're welcome

or you could skip local and just test remotely

of course it's from Skye

rude

I said it was cursed when I wrote it!

yeah I would never write anything like that. I prefer something like this instead

(message.ack ?? (() => {}))()

it is clearly more self documenting and helps the reader understand what the author was intending

yeah, eventually this will be what we do (split out backend auth stuff completely). But smart placement would be an easier solution.

We have passed this feedback on to the Smart Placement team in the past, hopefully it learns on an endpoint basis in future